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Abstract 

Programming  computers  is  a  notoriously  error-prone  process.  It  is  the  job  of  the  program¬ 
ming  language  designer  to  make  this  process  more  reliable.  One  approach  to  this  is  to 
impose  some  sort  of  typing  discipline  on  the  programs.  In  doing  this,  the  programming 
language  designer  is  immediately  faced  with  a  tradeoff:  if  the  type  system  is  too  simple,  it 
cannot  accurately  express  important  properties  of  the  program;  if  it  is  too  expressive,  then 
mechanically  checking  or  inferring  the  types  becomes  impractical.  This  thesis  describes 
a  type  system  called  refinement  types,  which  is  an  example  of  a  new  way  to  make  this 
tradeoff,  as  well  as  a  potentially  useful  system  in  itself. 

Refinement  type  inference  requires  programs  to  have  types  in  two  type  systems:  an 
expressive  type  inference  system  (intersection  types  with  subtyping)  and  a  relatively  simple 
type  system  (basic  polymorphic  type  inference).  Refinement  type  inference  inherits  some 
properties  from  each  of  these:  as  in  intersection  types  with  subtyping,  we  can  use  the  type 
system  to  do  abstract  interpretation;  as  in  basic  polymorphic  type  inference,  refinement  type 
inference  is  decidable  (preliminary  experiments  suggest  refinement  type  inference  may  be- 
practical  as  well). 

We  have  implemented  refinement  type  inference  for  a  subset  of  Standard  ML  to  test  these 
ideas.  We  have  added  new  syntax,  called  rectype  declarations,  to  allow  the  programmer 
to  specify  relevant  domains  for  the  abstract  interpretation.  A  prototype  implementation  of 
refinement  type  inference  can  do  some  interesting  case  analysis  for  Standard  ML  programs; 
for  example,  if  the  programmer  uses  a  rectype  declaration  to  declare  interest  in  whether 
a  boolean  expression  is  in  conjunctive  normal  form  (CNF),  refinement  type  inference 
can  efficiently  prove  that  a  function  for  converting  boolean  expressions  to  CNF  does 
indeed  always  return  a  boolean  expression  in  CNF.  Rectype  declarations  and  refinement 
type  inference  seem  flexible  and  efficient  enough  to  practically  enforce  many  other  useful 
program  properties  as  well. 
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Chapter  1 
Introduction 


In  this  chapter  we  use  examples  to  illustrate  what  refinement  type  inference  can  and  cannot 
do.  We  also  describe  the  context  in  which  this  thesis  exists,  and  give  an  overview  of  the 
rest  of  the  thesis. 


1.1  Introductory  Examples  of  Refinement  Types 

The  examples  in  this  chapter  are  in  Standard  ML.  The  first  example  defines  a  Standard  ML 
function  that  returns  the  last  cons  cell  in  a  list: 

datatype  a  list  =  nil  |  cons  of  a  *  a  list 
fun  lastcons  (last  as  cons  (hd,  nil))  -  last 
I  lastcons  (cons  (hd,  tl))  =  lastcons  tl 

Readers  unfamiliar  with  Standard  ML  will  benefit  from  some  explanation  of  this:  The  first 
line  is  a  datatype  declaration  that  defines  the  ML  type  constructor  list  to  mean  LISP-like 
lists  where  all  elements  have  the  same  type.  The  type  of  the  elements  is  the  argument  to  the 
type  constructor;  for  example,  since  int  is  the  type  of  integers,  int  list  is  the  type  of  lists 
of  integers.  (The  type  is  not  written  list  int;  unlike  function  application,  type  application 
is  written  in  postfix.)  This  declaration  also  states  that  the  constructors  cons  and  nil  can  be 
used  to  construct  lists. 

The  second  and  third  lines  are  the  definition  of  the  function  lastcons.  A  function 
definition  in  Standard  ML  consists  of  the  keyword  fun  followed  by  one  or  more  cases 
consisting  of  a  function  name,  a  pattern,  an  and  an  expression.  Each  time  the  function 
is  called,  the  first  pattern  that  matches  the  actual  argument  is  selected  and  used  to  bind 
variables,  the  corresponding  expression  is  evaluated,  and  the  resulting  value  is  returned. 
The  first  pattern  (last  as  cons  (hd,  nil))  binds  the  variable  last  to  the  argument 
and  also  matches  the  pattern  cons  (hd,  nil)  against  the  argument;  this  checks  that  the 
outermost  constructor  is  cons  and  the  second  argument  to  cons  is  nil.  If  this  is  so,  then 
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we  bind  hd  to  the  first  element  of  the  list  cons  and  return  last.  The  second  pattern 
(cons  (hd ,  tl))  matches  any  nonempty  list.  Since  the  first  pattern  matched  lists  of  length 
one,  the  expression  corresponding  to  this  pattern  will  only  be  evaluated  when  the  list  has 
two  or  more  elements. 

The  empty  list  nil  is  not  matched  by  any  pattern.  This  causes  SML  compilers  to 
generate  a  warning  during  type  inference  that  not  all  cases  are  accounted  for,  and  an  error  at 
run  time  if  the  value  nil  is  passed  to  lastcons.  With  refinement  types,  we  can  do  better  by 
making  a  declaration  that  distinguishes  empty  lists  from  nonempty  lists.  Then  refinement 
type  inference  will  always  generate  a  warning  when  lastcons  is  used  and  the  missing 
case  is  reachable,  and  it  will  often  remain  silent  when  the  missing  case  of  lastcons  is 
unreachable.  Assuming  we  eliminate  the  warning  generated  by  SML  type  inference  for  the 
missing  case,  the  net  result  is  fewer  and  more  specific  warnings. 

Standard  ML  also  allows  matching  against  patterns  without  making  a  function  call.  For 
example,  the  expression 


case  lastcons  y  of 

cons  (x,  nil)  =>  print  x 


prints  the  unique  element  of  the  list  returned  by  lastcons.  This  expression  gets  a  compiler 
warning  for  the  same  reason  as  the  definition  of  lastcons:  the  compiler  sees  that  not  all 
cases  are  dealt  with.  Once  again,  we  can  use  refinement  types  to  do  better.  If  we  make 
a  declaration  distinguishing  singleton  lists  from  other  lists,  refinement  type  inference  will 
infer  that  lastcons  always  returns  a  singleton  list  and  that  the  missing  branches  of  this 
case  statement  are  unreachable. 

Attempting  to  take  such  refined  type  information  into  account  at  compile  time  can  very 
quickly  lead  to  undecidable  problems.  The  key  idea  which  makes  our  type  system  decidable 
is  that  subtype  distinctions  (such  as  singleton  lists  as  a  subtype  of  arbitrary  lists)  must  be 
made  explicitly  by  the  programmer  in  the  form  of  recursive  type  declarations.  Since  the 
programmer  makes  a  finite  number  of  recursive  type  declarations,  we  have  a  finite  number 
of  distinctions  to  search  over  during  type  inference. 

In  the  example  above,  we  can  declare  the  refinement  type  of  singleton  lists  as 


datatype  a  list  •  nil  I  cons  of  a  *  a  list 
rectype  a  empty  =  nil 

and  a  singleton  -  cons  (a,  nil) 

and  a  long  =  cons  (a,  cons  (a,  a  T».0) 

and  a  =  bottom  (list) 


This  rectype  declaration  instructs  type  inference  to  distinguish  lists  of  length  0, 1,  and  2  or 
more  from  each  other.  If  we  think  of  refinement  types  as  sets,  then  I  corresponds  to  set  union. 
In  this  context,  the  value  constructors  cons  and  nil  operate  on  sets;  the  type  expression  nil 
stands  for  the  set  {nil}  and  cons(X,  Y )  stands  for  (cons(z,y)  j  x  e  X  and  y  €  F}.  The 
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expression  bottom  (list)  corresponds  to  the  empty  set  of  lists,  and  -L/Ut  a  refinement  type 
identifier  defined  by  this  declaration  to  stand  for  an  empty  set  of  lists.  (In  the  implementation, 
all  identifiers  are  ASCII,  so  we  cannot  use  the  name  -L|„£  as  an  identifier  directly;  instead 
we  use  bot_list.  In  the  text  of  this  thesis  we  are  not  limited  to  ASCII,  so  we  use  the  name 
-i-iijt  for  this  identifier.)  As  a  convenience,  the  system  also  provides  a  catch-all  refinement 
type  T iitt  that  includes  all  lists.  This  means  that  rectype  declaration  above  is  treated  as 
though  the  clause 


...  and  a  Tj^  =  nil  I  cons  (ci£*Tkj1) 


were  added.  (The  implementation  uses  top_list  instead  of  T «Jt.) 

One  way  to  think  of  the  refinement  type  inference  algorithm  is  that  it  performs  abstract 
interpretation  over  programmer- specified  finite  sets  of  refinement  types  (plural  here,  since 
each  ML  type  has  its  own  set  of  refinement  types).  Finiteness  is  important,  since  it  is 
necessary  for  the  decidability  of  refinement  type  inference.  With  the  above  declaration, 
abstract  interpretation  works  over  this  set  of  refinements  of  a  list: 


a  T  iut 


a  Uut 


The  system  ensures  that  the  intersection  of  any  two  refinement  type  constructors  is  also  a 
refinement  type  constructor,  so  if  we  omitted  the  declaration  of  ±u,t  the  lattice  would  look 
the  same,  except  the  position  of  would  be  occupied  by  an  automatically  generated 
name  instead. 

To  perform  the  abstract  interpretation,  the  type  system  needs  to  know  the  behaviors  of 
cons  and  nil  on  this  abstract  domain.  This  can  be  expressed  through  refinement  types 
given  to  the  constructor.  For  example,  cons  applied  to  anything  of  type  a  and  nil  will 
return  a  singleton  list; 


cons  :  (a*  a  empty)  — ►  a  singleton 

The  constructor  cons  also  has  other  types,  such  as: 

cons  :  (a  *  a  singleton)  — *  a  long 
cons  :  (a  *  a  long)  — *  a  long 

In  the  refinement  type  system,  we  express  the  principal  type  for  cons  by  using  the  intersec¬ 
tion  operator  “A”  to  combine  all  these  types,  resulting  in: 


4 


CHAPTER  1.  INTRODUCTION 


cons  :  (a*  a  empty)  —*  a  singleton  A 
(a  *  a  singleton )  —*  a  long  A 

(a  *  a  long)  —*  a  long 

This  type  for  cons  is  generated  automatically  from  the  rectype  declaration  above. 

We  can  also  use  refinement  types  to  analyze  polymorphic  functions.  For  example,  we 
can  define  the  usual  function  for  applying  a  function  to  each  element  of  a  list  and  making  a 
list  of  the  results  as  follows: 

fun  map  f  nil  -  nil 

I  map  f  (cons  (a,  b))  =  cons  (f  a,  map  f  b) 

This  function  has  the  polymorphic  ML  type  V(a,  /3).(a  — >  /3)  — >  a  list-*  (3  list.  With  the 
refinement  type  declarations  listed  above  in  effect,  it  has  the  refinement  type 

V(a,/?).(a  —*j3)—*(a  empty  — *  {I  empty  A 

a  singleton  —*  /3  singleton  A 
a  long  — *  ft  long). 

In  Chapter  4,  we  give  examples  where  polymorphism  interferes  with  refinement  type 
inference.  This  is  not  one  of  them;  expressions  using  polymorphic  map  always  get 
as  precise  a  refinement  type  as  similar  expressions  using  a  monomorphic  version  of 
map.  For  example,  the  best  refinement  type  for  cons  (nil ,  nil)  is  a  empty  singleton , 
and  the  best  refinement  type  for  map  (fn  x  *>  cons  (x,  nil))  (cons  (nil,  nil))  is 
a  empty  singleton  singleton.  Since  the  value  of  this  expression  is 

cons  (cons  (nil,  nil),  nil), 

this  is  the  best  type  we  could  hope  for. 

We  can  also  use  refinement  types  to  prove  that  certain  parts  of  a  program  do  not  use  some 
datatype  constructors.  Consider  a  compiler  for  a  toy  language  with  only  if  statements, 
case  statements,  and  variables,  where  if  statements  are  syntactic  sugar  for  case  statements 
that  operate  on  the  booleans.  It  is  possible  to  separate  a  compiler  for  this  language  into 
three  sections:  a  parser,  a  desugarer  that  rewrites  the  if  statements  to  case  statements,  and 
the  rest  of  the  compiler.  Since  the  rest  of  the  compiler  is  only  given  desugared  code,  it  does 
not  need  to  be  prepared  for  if  statements. 

To  formalize  this,  we  first  define  the  abstract  syntax  for  this  toy  language: 

datatype  pat  -  TRUE  1  FALSE 
datatype  syn  - 
VAR  of  string 
1  IF  of  syn  *  syn  *  syn 
I  CASE  of  syn  *  (pat  *  syn)  list 
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We  can  use  a  rectype  declaration  to  distinguish  desugared  abstract  syntax: 

rectype  desugared  - 
VAR  ( Tstrin, ) 

I  CASE  ( desugared  *  (TM<  *  desugared)  T u,t) 

We  omit  the  code  for  the  parser.  The  code  for  the  desugarer  is  straightforward: 

fun  desugar  (IF  (si,  s2,  s3))  » 

CASE  (desugar  si,  [(TRUE,  desugar  s2),  (FALSE,  desugar  s3)]) 

I  de sugar  (VAR  s)  =  VAR  s 
I  desugar  (CASE  (s,  1))  = 

CASE  (desugar  s,  map  (fn  (pat,  s')  =>  (pat,  desugar  s’))  1) 

This  gives  desugar  the  refinement  type  TJfn  — >  desugared.  For  the  purposes  of  this 
example,  our  only  concern  about  the  rest  of  the  compiler  is  to  show  that  refinement  type 
inference  can  verify  that  it  does  not  need  to  deal  with  the  IF  constructor  if  it  is  only  passed 
desugared  code  for  input.  It  is  possible  to  write  and  typecheck  a  caricature  of  the  rest  of  the 
compiler  by  first  defining  a  stub  datatype  for  the  output  of  the  compiler: 

datatype  code  *  CODE 

Then  we  define  the  rest  of  the  compiler  to  covert  all  syntax  it  expects  to  encounter  into  a 
CODE: 

fun  rest  (VAR  s)  =  CODE 
I  rest  (CASE  (s,  1))  = 

(rest  s; 

map  (fn  (pat,  s’)  =>  rest  s’)  1; 

CODE) 

In  this  case  refinement  types  can  verify  that  the  missing  IF  case  of  rest  is  never  reached 
if  its  argument  has  the  type  desugared. 

If  we  do  not  use  refinement  types,  a  dilemma  arises  as  we  write  this  code.  Either  we  can 
have  separate  datatypes  for  the  input  and  output  of  functions  like  de  sugar,  or  we  can  have 
one  datatype  and  add  unreachable  cases  to  rest  to  keep  the  ML  compiler  from  complaining. 
The  first  option  is  awkward  because  the  datatypes  defined  tend  to  be  redundant,  and  functions 
for  printing  out  these  datatypes  (among  others)  must  have  redundant  implementations.  The 
second  option  is  unattractive  as  well  because  the  compiler  does  not  check  that  the  added 
cases  are  unreachable,  and  because  we  have  forced  the  programmer  to  write  unnecessary 
code. 
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1.2  Practical  Examples  of  Refinement  Types 

Refinement  type  inference  is  practical  only  if,  in  a  reasonable  amount  of  time,  it  can  infer 
useful  information  that  is  not  immediately  obvious  to  a  human  programmer.  The  examples 
in  this  section  are  practical  in  that  sense;  the  prototype  implementation  needs  22  seconds 
elapsed  time  to  verify  them  on  a  SPARCstation  iPX  and  the  examples  are  complex  enough 
that  refinement  type  inference  found  an  error.  This  implementation  is  not  particularly 
efficient;  an  improvement  in  speed  by  a  factor  of  10  would  not  be  surprising. 

We  illustrate  the  practicality  of  refinement  types  with  some  code  for  manipulating 
boolean  expressions.  We  will  present  this  code  as  Standard  ML  syntax;  it  is  a  simple  matter 
to  translate  this  into  the  restricted  language  described  in  the  theory  or  the  language  of  the 
prototype.  The  assertions  below  about  the  behavior  of  refinement  type  inference  are  based 
on  the  behavior  of  the  implementation;  to  the  best  of  my  knowledge,  they  are  also  consistent 
with  the  theory  in  the  following  chapters. 

First,  we  can  define  boolean  expressions  with  the  declaration 

datatype  boolexp  ~  And  of  boolexp  *  boolexp 
I  Or  of  boolexp  *  boolexp 
I  Not  of  boolexp 
I  True 
I  False 

I  Var  of  string 

For  example,  the  expression  (s  A  y)  V  ->(®  A  y)  is  represented  as  the  value 

Or  (And  (Var  "x",  Var  "y").  Not  (And  (Var  "x",  Var  "y"))) 

One  simple  operation  we  can  do  with  a  boolean  expression  is  evaluate  it,  if  it  is  ground 
(that  is,  it  has  no  variables).  It  is  easy  to  write  a  function  to  do  this: 

fun  eval  (And  (bl,  b2))  =  aval  bl  andalso  aval  b2 
I  eval  (Or  (bl,  b2))  =  eval  bl  orelse  eval  b2 
1  eval  (Not  bl)  =  not  (eval  bl) 

1  eval  True  =  true 
I  eval  False  =  false 

Unfortunately,  presenting  this  definition  to  a  Standard  ML  system  yields  a  warning  that  the 
function  is  missing  a  case  for  the  Var  constructor.  This  is  reasonable,  since  we  did  not  tell 
the  compiler  that  we  only  intend  to  evaluate  ground  boolean  expressions.  With  refinement 
types,  we  can  tell  the  compiler  this,  and  it  can  check  that  eval  is  missing  no  cases  required 
to  evaluate  ground  boolean  expressions.  Refinement  types  can  also  ensure  at  compile  time 
that  all  expressions  passed  to  eval  are  ground. 

To  make  this  happen,  we  define  ground  boolean  expressions  with  a  rectype  declaration: 
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rectype  ground  -  True  I  False  I  Mot  ( ground )  I 

And  ( ground  *  ground)  |  Or  ( ground  *  ground) 

This  declaration  defines  a  refinement  type  ground.  Every  refinement  type  is  entirely 
contained  within  some  ML  type;  we  say  the  refinement  type  refines  the  ML  type.  In  this 
case,  ground  refines  boolexp.  The  rectype  statement  can  be  read  as  a  description  of  all 
the  ways  of  constructing  a  value  with  refinement  type  ground;  for  instance,  because  the 
rectype  statement  includes  the  clause  And  ( ground  *  ground),  it  is  possible  to  construct 
a  value  with  refinement  type  ground  by  applying  the  constructor  And  to  a  value  with 
refinement  type  ground  *  ground;  this  is  equivalent  to  saying  the  argument  to  And  must  be 
a  pair  of  values,  each  with  refinement  type  ground. 

A  refinement  type  called  T  \,ooU*f  containing  all  values  of  ML  type  boolexp  is  implicitly 
declared.  Without  this  there  would  be  no  refinement  type  for  non-ground  boolean  expres¬ 
sions,  which  would  essentially  mean  that  the  Var  constructor  would  cause  a  refinement 
type  error  whenever  it  is  used. 

With  the  declaration  of  ground,  refinement  type  inference  will  infer  that  eval  has  the 
refinement  type  ground  —*  T where  T 4^,/is  the  refinement  of  bool  that  includes  both 
true  and  false.  As  long  as  refinement  type  inference  can  infer  that  the  argument  passed 
to  eval  each  time  it  is  called  has  refinement  type  ground,  there  will  be  no  warning  and  no 
need  for  a  warning  because  the  missing  case  in  eval  will  not  be  reached. 

Refinement  types  can  also  be  used  to  infer  useful  things  about  the  result  of  substituting 
values  for  variables  in  boolean  expressions.  This  requires  manipulating  substitutions;  we 
will  represent  a  substitution  as  a  value  with  the  type  ( string  *  boolexp)  list, where  the  first- 
element  of  each  pair  in  the  list  is  the  name  of  the  variable  and  the  second  is  the  corresponding 
value.  An  elementary  operation  on  substitutions  is  looking  up  a  value  in  a  substitution, 
which  can  be  implemented  with  the  code: 

fun  lookup  (cons  ((stl,  v),  tl))  st2  = 

if  stl  =  st2  then  v  else  lookup  tl  st2 
I  lookup  []  _  =  error  () 

If  we  assume  error  has  the  ML  type  a  — >  (3,  then  lookup  gets  the  ML  type  (a  * 
(3)  list  — ♦  a  — ►  /?,  where  we  underline  type  variables  for  which  polymorphic  equality  must 
be  defined.  The  refinement  type  inferred  for  it  is  similar:  (a  *  /?)  T u,t  — ►  a  — >  (3. 

When  we  instantiate  the  ML  type  variables  a  and  /?,  the  corresponding  refinement 
type  variables  can  be  instantiated  to  any  refinement  of  the  ML  type  substituted  for  the 
corresponding  ML  type  variable.  For  example,  consider  the  instantiation  mapping  a  to 
string  and  (3  to  boolexp.  Instantiating  the  ML  type  (a  *  f3)  list  — >  a  — » (3  yields  the  ML 
type  ( string  *  boolexp)  list  — +  string  — >  boolexp.  We  will  suppose  that  T,WnJ  refines  string; 
since  T  ko0iexp  refines  boolexp,  instantiating  the  refinement  type  {a*  {3)  T  u,t  —>  a—>  f3  yields 

((Tjfrtnj  *  T  tyaoUrp  )  list  >  T  ttring  *  T  iooleif- 
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Since  ground  also  refines  boolexp ,  instantiating  it  also  yields 

*  ground)  list  ->  T  ,tTinl  -*  ground. 

We  can  combine  multiple  refinement  types  of  an  expression  with  A,  so  lookup  also  has  the 
refinement  type 

( T tiring  *  ground)  list  -*  Tttrinf  -> ground  A  (T„„n#  *  T boolexp)  list  ->  T  string  *  T  boolexp  • 

Now  we  can  use  lookup  to  implement  a  function  for  applying  a  substitution: 

fun  apsubst  (And  (bl,  b2))  s  = 

And  (apsubst  bl  s,  apsubst  b2  s) 

I  apsubst  (Or  (bl,  b2))  s  = 

Or  (apsubst  bl  s,  apsubst  b2  s) 

I  apsubst  (Not  bl)  s  =  Not  (apsubst  bl  s) 

I  apsubst  (Var  st)  s  =  lookup  s  st 
I  apsubst  x  _  =  x 

and  with  refinement  types  we  can  infer  that  this  function  has  the  type 

T boolexp  -*(T string  *  ground)  T Klt  -*•  ground, 

which  means  that  applying  a  ground  substitution  to  any  boolean  expression  yields  a  ground 
boolean  expression  (or  raises  an  exception). 

We  can  also  use  refinement  types  to  reason  about  boolean  expressions  in  conjunctive 
normal  form  (CNF).  We  can  distinguish  these  with  the  following  roctype  declaration: 

rectype  cnf  =  And  (cn/  *  cnf)  |  disj  |  True 
and  disj  =  Or  (disj  *  disj)  |  literal  |  False 
and  literal  =  Not  (atom)  i  atom 
and  atom  =  Var  (T,tri„9) 

As  an  example  of  the  use  of  this  rectype  statement,  we  can  write  a  function  to  convert 
boolean  expressions  into  CNF,  and  use  refinement  types  to  verify  that  it  always  returns  an 
expression  in  CNF.  We  define  the  function  in  two  steps;  the  first  step  is  to  transform  the 
disjunction  of  two  expressions  in  CNF  into  an  expression  in  CNF: 

fun  disjCnfs  (And  (bl,  b2))  c  =  And  (disjCnfs  bl  c,  disjCnfs  b2  c) 

I  disjCnfs  True  c  =  True 
I  disjCnfs  b  (And  (cl,  c2))  = 

And  (disjCnfs  b  cl,  disjCnfs  b  c2) 

I  disjCnfs  b  True  =  True 
I  disjCnfs  b  c  »  Or  (b,  c) 
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Type  inference  infers  that  dis  jCnf  s  has  the  refinement  type  cnf  — »  cnf  — ♦  cnf,  among 
others. 

An  earlier  version  of  this  had  an  error  that  was  found  when  the  earlier  definition  did  not 
have  the  correct  refinement  type.  The  version  with  the  error  was 

fun  disjCnfs  (And  (bl,  b2))  c  =  And  (disjCnfs  bl  c,  disjCnfs  b2  c) 

I  disjCnfs  True  c  =  True 
I  disjCnfs  (b  as  Or  _)  (And  (cl,  c2))  = 

And  (disjCnfs  b  cl,  disjCnfs  b  c2) 

1  disjCnfs  (b  as  Or  _)  True  =  True 
I  disjCnfs  b  c  =  Or  (b,  c) 

An  example  of  the  error  is  disjCnfs  False  (And  (False,  False));  this  evaluates  to 

Or  (False,  And  (False,  False)), 

which  is  not  in  CNF,  even  though  both  of  the  arguments  to  disjCnfs  are  in  CNF.  The 
prototype  implementation  detected  the  error  when  it  was  told  to  check  the  assertion  that 
disjCnfs  has  the  type  cnf  — ► cnf  — >  cnf  ;  the  command  to  do  this  is  written  as 

val  _  *  disjCnfs  <1  cnf  — >  cnf  — >  cnf 

(Actually,  the  prototype  implementation  only  takes  ASCII  characters  for  input,  so  it  is  really 
written 


val  _  =  disjCnfs  <:  cnf  ->  cnf  ->  cnf 

However,  since  the  implementation  is  a  research  prototype  rather  than  a  practical  tool  at  this 
point,  readability  is  more  important  than  gritty  realism,  so  we  will  typeset  all  discussion  of 
the  implementation.) 

After  we  can  convert  the  disjunction  of  two  CNF  boolean  expressions  to  CNF,  it  is  easy 
to  convert  arbitrary  boolean  expressions  to  CNF: 

fun  toCnf  (And  (bl,  b2))  =  And  (toCnf  bl,  toCnf  b2) 

I  toCnf  (Or  (bl,  b2))  *  disjCnfs  (toCnf  bl)  (toCnf  b2) 

I  toCnf  (Not  (And  (bl,  b2)))  =  toCnf  (Or  (Not  bl.  Not  b2)) 

I  toCnf  (Not  (Or  (bl,  b2)))  =  toCnf  (And  (Not  bl.  Not  b2)) 

I  toCnf  (Not  True)  =  False 
I  toCnf  (Not  False)  =  True 
I  toCnf  (Not  (Vax  s))  =  Not  (Var  s) 

I  toCnf  z  =  z 


The  prototype  implementation  can  infer  that  toCnf  has  the  refinement  type  T  ioouir  — *  cnf. 
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1.3  Related  Work 

The  main  features  of  refinement  type  inference  -  basic  polymorphic  type  inference,  sub¬ 
typing,  intersection  types,  and  rectype  declarations  -  are  all  derived  from  features  of 
languages  that  have  appeared  in  the  literature. 


1.3.1  Basic  Polymorphic  Type  Inference 

A  dynamically  typed  language  like  LISP  can  have  one  function  that  can  append  any  kinds  of 
lists,  whether  those  lists  contain  integers,  booleans,  or  other  lists.  Parametric  polymorphism 
provides  some  of  this  flexibility  to  statically  typed  languages.  In  this  example,  we  start 
by  assuming  all  elements  of  the  lists  have  the  same  type;  we  will  name  this  type  with 
a  parameter,  say  a.  Then,  for  all  a,  the  function  that  appends  lists  (call  it  append)  can 
have  the  type  a  list  — » a  list  — ►  a  list.  We  can  see  that  this  function  can  append  lists 
of  booleans  by  first  instantiating  a  to  bool ,  to  conclude  that  append  also  has  the  type 
bool  list  — >  bool  list  — >  bool  list. 

Standard  ML  is  a  language  with  parametric  polymorphism  that  has  been  developed  for 
at  least  15  years  [Mil78,  MTH90,  MT91b,  Har86,  HMM+88,  Tof87,  Tof88,  DM82,  Mac88]; 
practical  implementations  are  freely  available.  Standard  ML  has  the  added  advantage  that 
the  polymorphism  is  implicit,  which  means  that  no  types  need  be  mentioned  in  the  definition 
of  functions  such  as  append;  instead,  they  can  all  be  inferred. 

Refinement  type  inference  simply  uses  polymorphic  type  inference  with  minimal 
changes.  Ultimately,  we  hope  to  have  a  dialect  of  Standard  ML  that  will  accept  all  existing 
SML  programs,  as  well  as  SML  programs  with  rectype  declarations  added.  Since  a  large 
body  of  SML  code  already  exists,  this  may  lead  to  widespread  use  of  refinement  types  fairly 
soon  after  good  implementations  of  refinement  types  are  available. 


1.3.2  Subtyping 

Roughly  speaking,  one  type  is  a  subtype  of  another  if  all  values  with  the  first  type  also 
have  the  second  type.  For  example,  in  mathematics,  all  integers  are  real  numbers,  so 
programming  languages  often  have  the  type  of  integers  (which  we  shall  call  int)  as  a 
subtype  of  the  type  of  real  numbers  (which  we  shall  call  real).  Since  integers  are  often 
implemented  differently  from  real  numbers,  the  simple  notion  of  subtyping  as  containment 
is  not  necessarily  true  at  the  implementation  level;  instead,  we  may  have  to  use  some 
non-trivial  function  to  coerce  elements  of  the  subtype  into  elements  of  the  supertype.  In 
this  example,  the  coercion  function  maps  the  machine  representations  of  integers  into  the 
machine  representations  of  reals. 

Subtyping  at  a  base  type  leads  naturally  to  subtyping  at  higher  types;  for  example,  if  int 
is  a  subtype  of  real,  then  we  would  expect  (inf  *  inf )  to  be  a  subtype  of  ( real  *  real).  We 
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also  have  the  slightly  counter-intuitive  assertion  that  real  — »  bool  is  a  subtype  of  ini  — >  bool; 
this  is  the  case  because  any  element  of  the  former  can  be  converted  to  an  element  of  the 
latter  by  first  coercing  the  argument  of  the  function  from  ini  to  real. 

Subtyping  also  has  a  natural  interpretation  when  used  with  records.  Any  record  with, 
say,  both  age  and  name  fields  has  an  age  field;  if  we  rephrase  this  in  terms  of  subtyping 
and  standard  notation  for  record  types,  and  assuming  that  the  age  field  is  an  int  and  the 
name  field  is  a  string,  we  say  that  {age  :  int , name  :  string}  is  a  subtype  of  {age  :  int}. 
Several  approaches  to  clean  interaction  between  this  kind  of  subtyping  and  polymorphism 
are  [JM88,  Jat89,  R89,  LW91,  HP91,  HL94],  These  are  all  type  inference  systems  that 
in  some  sense  extend  the  type  inference  of  Standard  ML;  making  a  version  of  refinement 
types  that  is  based  on  one  of  these  instead  of  Standard  ML  is  potential  future  work. 

Two  papers  by  Fuh  and  Mishra  [FM89,  FM90]  describe  an  interesting  system  that  deals 
simultaneously  with  polymorphism  and  subtyping.  Like  refinement  types,  their  system 
permits  a  user-defined  subtyping  relation,  but  unlike  refinement  types  their  system  has  no 
intersection  operator.  In  their  system  the  result  of  type  inference  is  a  pair,  consisting  of 
a  type  and  a  set  of  constraints  that  may  stipulate  that  some  free  type  variables  appearing 
in  the  type  must  be  subtypes  of  one  another.  It  is  not  clear  how  to  extend  this  system  to 
include  intersections. 

Subtyping  in  refinement  types  is  simpler  than  subtyping  in  general  because  with  refine¬ 
ment  types,  the  coercion  function  is  always  the  identity  function. 

1.3.3  Intersection  Types 

Intersection  types  record  multiple  pieces  of  information  about  an  expression.  For  example, 
consider  a  unary  negation  operator  that  applies  to  both  integers  and  reals.  It  will  therefore 
have  both  of  the  types  int  —*  int  and  real  — *  real.  Therefore,  if  we  have  intersection  types 
in  our  language,  we  can  say  it  has  the  type  ( int  — *  int)  A  (real  — »  real).  When  the  type 
system  uses  the  type  of  unary  negation,  it  will  have  to  select  an  appropriate  type  from  the 
ones  intersected. 

These  types  can  quickly  become  too  expressive;  type  inference  becomes  undecidable 
[CDCV80].  There  are  restrictions  that  yield  a  decidable  system  [CG92],  but  it  is  not  clear 
what  subtyping  means  in  this  system. 

Another  variant  of  this  is  Forsythe  [Rey88J.  This  language  has  intersection  types  and 
subtyping,  but  no  polymorphism.  This  language  has  a  different  approach  to  records  from 
the  polymorphic  one  mentioned  above;  the  intersection  of  the  two  record  types  {age  :  int} 
and  {name  :  string}  is  {age  ;  inf,  name  :  string}. 

Yet  another  option  is  FA  [Pie91b],  This  language  has  intersection  types,  subtyping, 
and  polymorphism,  and  its  type  system  can  encode  any  of  the  abstract  interpretations  that 
refinement  type  inference  can.  However,  it  has  explicit  types,  and  type  checking  in  this 
system  is  undecidable. 
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1.3.4  Rectype  Declarations 

Rectype  declarations  essentially  define  finite  automata  that  recognize  when  a  value  is  in  a 
refinement  type.  In  fact,  as  long  as  there  are  no  function  types,  a  rectype  declaration  has 
exactly  the  same  descriptive  power  as  a  regular  tree  automaton  [GS84],  Similar  automata 
have  been  used  to  define  types  for  logic  programs;  most  of  the  papers  in  [Pfe921  deal  with 
some  aspect  of  this.  For  example,  [YFS92,  page  68]  uses  the  example 

Evenlist(T\,T2)  ::=  [];  [tj  |  Oddliat(TUT2)\. 

Oddlist(T\,T2)  ::=  [t2  |  Evenlist(TX,T2)}. 

which  is  remarkably  similar  to  (and  probably  derived  independently  from)  the  example  we 
will  use  in  the  next  chapter: 

datatype  blist  -  nil  I  cons  of  bool  *  blist 
rectype  bev  -  cons  (T ^oJ  *  bod)  I  nil  ( runit ) 
and  bod  =  cons  (Tj00i  *  bev) 

The  operations  needed  to  determine  the  meaning  of  a  rectype  declaration  can  be 
computed  exactly  for  regular  tree  automata  [GS84).  The  algorithms  given  for  regular  tree 
automata  in  [DZ92]  seem  practical,  and  assuming  they  are  sound,  they  are  more  accurate 
than  the  type  system  given  in  Chapter  3.  An  example  where  the  current  specification  is 
weak  is  on  page  193.  Finding  a  practical  algorithm  that  works  well  in  the  general  case  and 
is  exact  in  the  case  when  there  are  no  function  objects  is  future  work. 


1.4  Claims  of  the  Thesis 

The  central  claim  of  this  thesis  is: 

Refinement  types  provide  a  sound,  practical,  declarative,  and  unobtrusive  way 
to  express  and  effectively  verify  some  reasoning  by  cases  about  Standard  ML 
programs  and  potentially  programs  in  other  functional  programming  languages. 

This  has  several  parts: 

•  Refinement  types  can  express  reasoning  by  cases  about  Standard  ML  programs.  This 
requires  subtyping  (because  some  cases  include  others)  and  intersection  types  (to 
describe  the  behavior  of  functions  on  multiple  possible  inputs). 

•  Refinement  types  can  be  effectively  verified.  This  means  that  type  inference  is 
decidable;  we  ensure  this  by  only  distinguishing  cases  in  which  the  programmer  has 
declared  interest  and  by  requiring  expressions  with  a  refinement  type  to  always  have 
an  ML  type. 
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•  Refinement  type  inference  is  practical.  This  thesis  demonstrates  this  by  describing  a 
prototype  implementation  of  it  that  has  tolerable  performance. 

•  Refinement  type  inference  is  sound.  We  exhibit  a  soundness  proof. 

•  Refinement  type  inference  is  declarative.  Refinement  type  inference  can  be  described 
with  a  declarative  type  inference  system.  See  Figure  2.6  on  page  60. 

•  Refinement  type  inference  is  unobtrusive.  If  rectype  declarations  and  “<J”  are  not 
used  in  a  program,  then  that  program  has  a  refinement  type  if  and  only  if  it  has  an  ML 
type.  Refinement  types  are  also  unobtrusive  in  the  sense  that  they  do  not  necessarily 
have  any  effect  on  execution.  Given  a  program  that  checks  refinement  types,  it  is 
easy  to  construct  a  compiler  for  a  variant  of  Standard  ML  that  has  refinement  types: 
the  compiler  could  simply  check  refinement  types,  remove  all  rectype  declarations 
and  uses  of  “<1”  from  the  given  source  code,  and  then  pass  the  resulting  source  code 
to  a  Standard  ML  compiler. 

1.5  Outline  of  the  Work 

This  thesis  starts  with  a  careful  formal  description  of  monomorphic  refinement  type  infer¬ 
ence.  Chapter  2  centers  around  the  inference  rules  in  Figure  2.6  that  describe  refinement 
type  inference  for  expressions  in  terms  of  explicit  assumptions  about  properties  of  the  in¬ 
formation  from  rectype  statements.  The  rest  of  that  chapter  consists  of  proofs  that  this 
type  inference  system  is  sound,  has  principal  types,  and  is  decidable. 

Chapter  3  deals  with  rectype  statements.  The  central  inference  systems  are  Figure  3.6, 
which  describes  how  to  infer  a  subtyping  relation  from  a  rectype  declaration,  and  Fig¬ 
ure  3.8,  which  describes  how  to  infer  the  splitting  relation.  The  rest  of  the  chapter  consists 
of  proofs  that  the  assumptions  made  in  Chapter  2  are  satisfied,  and  a  proof  that  refinement 
type  inference  for  values  is  consistent  with  a  semantics  we  give  for  rectype  statements. 

Chapters  4  and  5  describe  how  to  add  polymorphism  to  this.  Chapter  4  simply  adds 
type  variables  such  as  a,  and  is  fairly  simple.  Chapter  5  add  type  constructors  that  take 
type  arguments,  such  as  a  list.  This  is  more  complex  because  we  have  to  dead-'  whether, 
for  example,  ( bev  A  bod)  singleton  <  bev  singleton.  There  are  four  possible  ways  a 
refinement  type  constructor  can  change  when  we  replace  its  argument  by  a  larger  argument: 
either  it  gets  larger,  gets  smaller,  stays  the  same,  or  the  new  type  is  incomparable  with  the 
old.  We  call  these  type  arguments  positive,  negative,  ignored,  and  mixed,  respectively. 
It  is  possible  to  create  examples  of  all  of  these  behaviors,  and  the  theory  has  to  deal  with 
them.  Chapter  5  describes  the  changes  necessary  to  the  reasoning  in  Chapters  2  and  3  to 
accommodate  this. 

Chapter  6  describes  how  to  add  the  coercion  operator  <1  to  the  language.  This  is  very 
straightforward,  provided  one  erases  all  coercion  operators  from  terms  before  evaluating 
them. 
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Chapter  7  describes  the  prototype  implementation.  The  fundamental  decision  made 
in  the  implementation  was  to  implicitly  represent  refinements  of  functional  ML  types  as 
functions.  Memoization  is  used  extensively.  We  find  fixed  points  by  using  pending  analysis 
[Jag89,  Dix88],  and  we  instantiate  polymorphic  refinement  types  using  a  novel  unproven 
strategy  that  appears  to  yield  correct  answers  in  practice. 


Chapter  2 

Refinement  Type  Inference 

2.1  Introduction 


This  chapter  gives  a  formal  description  of  a  simple,  monomorphic  form  of  refinement  types 
that  includes  only  primitives  for  functional  programming  and  assumes  that  the  programmer 
has  already  declared  which  distinctions  he  is  interested  in.  In  Chapter  3,  we  describe 
rectype  statements,  which  allow  the  programmer  to  declare  interest  in  specific  distinctions. 
The  soundness  results  of  this  chapter  depend  on  several  assertions  that  are  proved  in 
Chapter  3.  These  assertions  are  labeled  as  “Assumptions”;  for  example,  the  first  one 
below  is  Assumption  2.2  (Constructors  have  Unique  ML  Types)  on  page  26.  Chapter  4 
expands  the  type  inference  in  this  chapter  to  include  type  variables,  and  then  Chapter  5  adds 
polymorphic  constructors. 

Perhaps  the  simplest  example  of  refinement  types  is  being  able  to  reason  about  the 
booleans.  If  the  programmer  has  declared  interest  in  the  distinction  between  true  and 
false,  refinement  type  inference  can  determine  that  the  function 

fn  x  =>  or  (x,  not  x) 

always  returns  true  regardless  of  its  input.  To  express  this  formally,  we  say 

h  fn  x  =>  or  (x,  not  x)  :  T — *  tt. 

Here  T  tt,  and  0i~+tt  are  all  refinement  types.  Informally  we  can  think  of  refinement 
types  as  standing  for  sets  of  values.  The  refinement  type  T  ^  is  the  set  of  all  boolean 
values,  or  {true,  false};  tt  is  the  set  {true};  and  T booi~*tt  is  the  set  of  all  functions 
with  ML  type  bool  —*  bool  that  map  all  values  in  T to  values  in  tt. 

If  we  think  of  refinement  types  as  sets  of  values,  each  value  in  the  set  must  have  the 
same  ML  type;  we  say  that  the  refinement  type  refines  the  ML  type.  For  example,  T  ^ 
refines  bool  and  T^j  — ♦  tt  refines  bool  — » bool.  For  the  purposes  of  the  examples  in  this 
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chapter,  the  refinements  of  bool  are 

T corresponding  to  the  set  {true,  false} 
tt,  corresponding  to  the  set  {true} 
ff,  corresponding  to  the  set  {false} 

-Lfeai,  corresponding  to  the  set  {} 

where  the  symbol  lie, i  is  a  typeset  version  of  the  name  bot_bool.  The  symbols  “J.”  and 
“T”  by  themselves  have  no  meaning  in  this  thesis. 

This  example  has  some  special  features  that  will  not  hold  in  general.  Although  there  is 
always  a  least  refinement  of  every  ML  type,  in  general  there  may  be  values  of  that  refinement 
type,  unlike  this  example  where  there  are  no  values  of  type  -L^.  The  simplest  instance 
of  this  arises  when  the  programmer  has  not  asked  for  any  refinement  type  distinctions; 
when  this  happens,  there  is  exactly  one  refinement  of  each  ML  type,  and  there  are  always 
values  with  that  refinement  type.  Since  we  want  the  programmer  to  have  the  option  of 
ignoring  refinement  types,  and  having  multiple  refinements  of  an  ML  type  slows  down  type 
inference,  we  should  only  have  multiple  refinements  of  an  ML  type  when  the  programmer 
asks  for  it. 

In  this  example,  there  is  a  maximal  refinement  T^j.  In  Chapter  5  we  will  mention 
examples  involving  polymorphism  where  there  is  no  maximal  refinement  type. 

In  Forsythe  [Rey88],  there  is  a  maximal  type  called  “ns”.  Every  Forsythe  expression 
has  this  type,  possibly  among  others;  when  the  type  system  detects  that  an  expression  is 
ill-behaved,  it  has  only  the  type  ns.  We  do  not  take  this  approach.  Instead,  the  refinement 
type  system  takes  the  more  conventional  approach  of  ensuring  that  ill-behaved  expressions 
have  no  type.  This  begins  to  be  inconvenient  in  Section  2.9,  where  to  simplify  the  statement 
of  some  theorems  we  introduce  the  notion  of  “generalized  refinement  types”,  each  of  which 
is  either  a  refinement  type  or  ns.  Even  then,  ns  is  not  the  refinement  type  of  any  expression. 

The  meaning  of  ns  is  entirely  different  from  the  meaning  of  T  There  are  perfectly 
well-behaved  expressions  with  the  refinement  type  T however,  ns  is  not  a  refinement 
type,  and  it  is  not  used  to  describe  the  behavior  of  well-behaved  expressions. 

According  to  the  above  list  of  the  refinements  of  bool,  the  intersection  of  two  refinements 
of  bool  is  a  refinement  of  bool.  This  is  a  desirable  property,  but  we  need  to  add  an  operator  to 
make  it  continue  to  hold  for  refinements  of  other  ML  types;  for  example,  with  the  notation 
introduced  so  far,  we  cannot  write  a  refinement  type  that  is  the  intersection  of  tt-*  ff  and 
ff  — *•  tt.  We  will  call  this  operator  “A”.  For  example,  here  are  some  of  the  refinements  of 
bool  — >  bool  and  some  of  the  elements  of  the  set  corresponding  to  each  one: 

T  id -*tt  contains  the  elements  fn  x  =>  true 

and  f n  x  =v  or  (x ,  not  x) 
tt-*ff  A  ff  — *  tt  contains  the  elements  not 

andfn  x  =>  or  (not  x,  not  x) 

Ttoo/  — *  Tm  contains  all  values  with  ML  type  bool  —*  bool 
tt  -*  T  I,,!  A  T**,*  — ►  tt  is  equivalent  to  T  — *  tt 
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Two  refinement  types  are  equivalent  if  they  correspond  to  sets  with  the  same  elements, 
otherwise  they  are  distinct.  For  instance,  the  refinement  type  tt  A  ff  A  tt  is  equivalent 
to  J-fcwj.  A  largest  set  of  distinct  refinements  of  bool  is  {T iaot,  tt,ff,  so  bool  has 

only  finitely  many  distinct  refinements.  It  turns  out  that  all  ML  types  only  have  finitely 
many  distinct  refinements;  this  is  true  for  datatypes  because  the  programmer  only  has  time 
to  specify  a  finite  number  of  distinctions,  and  it  is  true  for  other  ML  types  because  the 
operators  ►”  and  we  use  to  construct  ML  types  from  other  ML  types  do  not  introduce 
infinite  numbers  of  distinct  refinements  where  there  were  none  before.  This  is  the  crucial 
property  that  makes  refinement  type  inference  decidable;  we  prove  it  in  Section  2.9. 

Refinement  types  become  more  interesting  and  useful  when  we  use  them  with  recursive 
datatypes.  A  simple  example  of  this  is  representing  nonnegative  integers  as  strings  of  bits: 

datatype  bitstr  =  Zero  of  bitstr  |  One  of  bitatr  I  Empty 

Suppose  the  least  significant  bits  are  outermost,  so  that  Zero  (One  Empty)  represents 
the  integer  2.  Every  nonnegative  integer  has  multiple  representations  in  this  system; 
for  example,  another  representation  of  2  is  Zero  (One  (Zero  Empty)).  Every  positive 
integer,  however,  does  have  exactly  one  representation  that  does  not  have  Zero  as  the  most 
significant  bit;  call  this  “normal  form”.  We  can  define  a  refinement  type  nf  containing  just 
the  positive  integers  in  normal  form,  and  we  can  prove  that  straightforward  functions  for 
doing  arithmetic  such  as 

fun  add  (One  bl)  (One  b2)  *  Zero  (add  (add  (One  Empty)  bl)  b2) 

1  add  (One  bl)  (Zero  b2)  =  One  (add  bl  b2) 

I  add  (Zero  bl)  (One  b2)  =  One  (add  bl  b2) 

I  add  (Zero  bl)  (Zero  b2)  =  Zero  (add  bl  b2) 

I  add  Empty  b  =  b 
I  add  b  Empty  ■  b; 

return  values  of  type  nf  when  passed  values  of  type  nf. 

Refinement  type  inference  determines  the  type  of  an  expression  by  first  finding  types 
for  the  subexpressions.  Thus,  we  can  only  discover  that  One  Empty  has  the  type  nf  if  we 
first  have  a  type  for  Empty.  We  will  call  that  type  em.  We  shall  assume  that  bitstr  has  the 
following  refinements' 

-Liitfir  corresponds  to  the  empty  set 
em  corresponds  to  {Empty} 

nf  corresponds  to  positive  integers  that  are  in  normal  form 
T i it.tr  corresponds  to  the  set  of  all  bitstrings 

In  this  case  the  set  of  values  of  type  nf  is  clearly  infinite.  This  makes  it  clear  that  any 
implementation  must  use  some  representation  of  refinement  types  other  than  sets  of  values. 
In  both  the  implementation  and  the  formal  description  of  refinement  types,  we  assign 
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refinement  types  to  constructors  instead  of  representing  refinement  types  as  sets  of  values. 
Since,  in  this  formalism,  values  are  expressions,  we  can  use  refinement  type  inference  to 
determine  which  values  are  in  which  refinement  types;  for  example,  the  assertion 

Zero  (On*  Empty)  €  nf 


becomes 

h  Zero  (One  Empty)  :  nf. 

In  this  chapter,  we  start  by  formally  defining  our  object  language  in  Section  2.2.  We 
also  describe  an  alternative,  more  concise  syntax  in  Section  2.3.  A  formal  semantics  is 
in  Section  2.4.  To  provide  background  for  the  description  of  refinement  types,  we  define 
a  restricted  version  of  the  usual  ML  type  system  in  Section  2.5.  A  simple  version  of 
refinement  types  is  defined  in  Section  2.6.  We  prove  that  it  is  compatible  with  ML  type 
inference  in  Section  2.7,  and  sound  in  Section  2.8.  We  show  that  each  ML  type  has  finitely 
many  refinement  types  in  Section  2.9,  and  use  this  fact  to  give  a  decision  procedure  for 
refinement  types  in  Section  2  10. 


2.2  The  Formal  Language 

Each  language  we  define  in  this  thesis  will  have  two  kinds  of  types.  The  more  familiar  kind 
resembles  the  one  commonly  used  for  SML;  we  shall  call  these  ML  types.  In  later  sections 
of  this  chapter  we  will  be  defining  more  informative  types  with  an  intersection  operator 
“A”;  we  shall  call  these  refinement  types. 

We  shall  use  the  metavariables  t  and  u  to  stand  for  ML  types  throughout  this  thesis. 
The  metavariable  tc  stands  for  an  ML  type  constructor,  so  we  can  define  the  language  of 
ML  types  with  the  grammar 

t  ::=  tc  \  t*  ...*t  \  tunit  \  t  — >  t. 

In  SML  the  type  of  a  zero-way  tuple  is  called  unit.  Here  we  call  it  tunit  instead  to 
distinguish  the  ML  type  for  empty  tuples  from  the  refinement  type  for  empty  tuples  that  we 
will  introduce  later. 

We  could  slightly  simplify  the  presentation  in  this  chapter  by  replacing  the  arbitrary- 
length  tuple  types  here  with  binary  and  nullary  tuples.  However,  when  we  introduce 
polymorphic  constructors  in  Chapter  5,  tuples  will  become  a  polymorphic  data  type  very 
similar  to  other  polymorphic  data  types,  and  at  that  point  arbitrary  length  tuples  will  add 
little  to  the  complexity  of  the  theory.  Thus  we  will  use  arbitrary  length  tuples  here  to 
simplify  the  analogy  between  the  system  described  in  this  chapter  and  the  system  described 
in  Chapter  5. 

We  use  x,  y,  and  /  as  metavariables  to  stand  for  object  language  variables,  c  to  stand 
for  constructors,  and  e  to  stand  for  expressions.  The  metavariables  x,  y,  and  /  that  appear 
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often  in  the  mathematics  should  not  be  confused  with  the  object  language  variables  x,  y, 
and  f  that  appear  often  in  the  examples.  Expressions  have  the  following  grammar: 

e::=  *  |  fn  x:t  =>  e  J  e  e  |  c  e  | 

case  e  of  c  *>  e  1  ...  |  c  =>  e  end:  t | 

(e,  ...,  e)  |  ()  |  elt_m_n  e  | 
fix  fit  *>  fn  x:t  ->  e 

Notice  that  this  grammer  uses  the  “|”  operator  as  meta-syntax  to  describe  a  language 
containing  the  character  I  in  the  syntax  of  case  statements.  This  language  is  roughly  a 
monomorphic  version  of  Mini-ML  [CDDK86]. 

As  the  grammar  says,  all  constructors  take  exactly  one  argument,  which  may  be  a  tuple. 
We  use  ()  to  mean  a  tuple  of  zero  elements.  Common  constructors  include  true  and  false; 
thus  true  is  not  a  syntactically  valid  expression  in  itself,  but  true  ()  is. 

There  are  explicit  types  appearing  at  several  places  in  the  grammar.  The  ML  types  after 
each  variable  binding  in  abstractions  and  fixed  points  ensure  that  each  expression  has  at 
most  one  ML  type  derivation;  the  need  for  this  is  discussed  in  the  next  section.  The  ML 
type  at  the  close  of  each  case  statement  prevents  obscure  pathological  behavior  that  would 
prevent  Theorem  2.54  (Inferred  Types  Refine)  on  page  68  from  being  true;  see  page  68  for 
a  discussion. 

As  in  Standard  ML  [MTH90,  MT91b],  the  fixed  point  operator  can  only  apply  to 
functions.  This  outlaws  oddities  such  as  fix  f  =>  not  f.  It  is  possible  that  the  theory 
below  could  be  adjusted  to  permit  recursive  values,  but  they  seem  troublesome  and  not 
particularly  useful,  so  we  shall  avoid  them. 


2.2.1  Explicit  or  Implicit  ML  Types 

One  of  the  major  features  of  SML  is  that  it  is  implicitly  typed.  This  frees  the  programmer 
from  most  of  the  burden  of  type  declarations.  Since  our  goal  is  to  analyze  Standard  ML, 
the  language  our  implementation  starts  with  must  also  be  implicitly  typed.  However,  since 
ML  type  inference  is  well  understood,  we  have  the  option  of  assuming  that  the  expressions 
analyzed  by  the  refinement  type  system  described  here  have  already  had  explicit  types 
inserted  by  ML  type  inference.  The  purpose  of  this  section  is  to  explain  why  we  take  this 
option. 

The  problem  with  implicit  ML  types  is  that  there  are  sometimes  multiple  derivations  of 
an  ML  type  for  an  expression.  For  example,  consider  the  SML  declaration 

val  foo  =  (fn  y  =>  (fn  z  =>  z))  (fn  x  =>  x) 

and  suppose  foo  has  the  ML  type  bool  — ►  bool.  Even  though  we  know  the  type  of  foo,  there 
are  still  many  different  ways  to  derive  this  type  because  we  can  give  the  subexpression 
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fn  x  *>  x  the  ML  type  bool  — ►  bool  or  ( bool  *  bool)  —*(bool  *  bool)  or,  in  general,  t—*t  for 
any  ML  type  t.  Once  we  add  polymorphic  type  variables  to  the  system  in  Chapter  4,  we  will 
be  able  to  give  examples  where  different  ML  type  derivations  lead  to  different  refinement 
types  for  the  expression. 

However,  it  seems  that  without  polymorphism,  the  refinement  type  assigned  to  an 
expression  depends  only  on  the  ML  type  assigned  to  the  expression,  not  on  how  that  type 
is  derived.  For  instance,  f  oo  has  the  ML  type  t—*t  for  any  t.  If  we  choose  an  ML  type  for 
f  oo  by  choosing  t  to  be  bool,  then  the  expression  has  a  principal  refinement  type 

tt-*tt  A  ff  — ATy- »  T  too/ A  i.^  — ♦  ±iooi 

that  does  not  depend  on  which  ML  type  we  assign  to  the  f  n  x  =>  x  subexpression.  It 
seems  that  the  ML  type  of  an  expression  uniquely  determines  its  principal  refinement  type  in 
general,  since  if  the  fn  x  =>  x  subexpression  were  used,  its  ML  type  would  be  constrained. 

Since  this  property  will  not  continue  to  hold  when  we  add  polymorphism,  it  seems  better 
to  add  explicit  types  to  the  terms  now  to  ensure  a  unique  ML  type  derivation  than  to  prove 
that  knowing  the  ML  type  is  sufficient  in  the  special  case  of  monomorphic  expressions.  To 
ensure  a  unique  ML  type  derivation,  we  write  the  ML  type  for  each  bound  variable.  For 
example,  the  two  derivations  mentioned  above  of  an  ML  type  for  f  oo  correspond  to  these 
translations  of  the  definition  of  f  oo  into  monomorphic  expressions: 

(fn  y :  bool— *  bool  =>  (fn  z:  bool  ->  z)) 

(fn  x:bool  ->  x) 


and 


(fn  y :  (bool  *  bool) —*(bool  *  bool)  =>  (fn  z:bool  ~>  z)) 

(fn  x:  bool  *  bool  =>  x). 

2.3  The  Concise  Language 

For  brevity,  we  will  want  to  have  implicit  types  in  our  examples.  Thus  we  shall  also  have 
an  informal,  concise  syntax  where  we  omit  the  types  with  the  understanding  that  the  real 
expression  has  some  consistent  ML  types  inserted.  This  notation  is  only  unambiguous 
when  the  concise  expression  has  a  unique  type  derivation.  Roughly  speaking,  our  concise 
language  is  the  subset  of  SML  that  can  be  easily  translated  to  fit  the  grammar  for  expressions 
on  page  19.  We  will  have  the  following  differences  between  the  concise  language  and  the 
formal  language: 

•  The  concise  language  has  constant  value  constructors,  but  in  the  formal  language 
all  constructors  take  one  argument.  Eliminating  constant  value  constructors  from 
the  formal  language  decreases  the  number  of  cases  that  have  to  be  considered  in  the 
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proofs.  Since  we  can  always  encode  a  constant  value  constructor  as  a  function  one 
that  takes  an  argument  of  ML  type  tunit,  this  does  not  decrease  the  expressiveness 
of  the  language. 

•  The  concise  language  uses  destructuring  in  f  n  expressions  to  extract  an  element  from 
a  tuple,  but  the  formal  language  uses  the  elt _m_n  primitive  to  extract  the  mth 
element  from  a  tuple  of  n  elements.  Eliminating  destructuring  from  f  n  expressions 
simplifies  the  proofs.  Encoding  the  length  of  the  tuple  in  the  operator  for  extracting 
elements  eliminates  some  ambiguity;  for  example,  in  SML  the  expression  #1  by  itself 
is  not  valid  because  it  is  not  clear  whether  to  give  it  the  type  a*  0  -*  a  or  the  type 
a*  0*-y  -*  a  or  one  of  the  infinitely  many  other  possibilities.  In  the  formal  language, 
this  sort  of  ambiguity  does  not  arise. 

•  The  concise  language  has  cas  e  statements  that  bind  variables,  but  the  formal  language 
does  not;  in  the  formal  language,  the  only  constructs  that  bind  a  value  to  a  variable 
are  abstractions  and  fixed  points.  For  instance,  if  we  assume  that  lists  of  booleans 
have  been  defined  with  the  datatype 

datatype  blist  =  nil  I  cons  of  bool  *  blist 
the  concise  expression 


case  cons  (true,  nil)  of 
cons  (x,  y)  =>  y 
I  nil  *>  nil 


corresponds  to  the  formal  expression 

case  cons  (true  (),  nil  ())  of 

cons  =>  fn  p :  bool  *  blist  =>  elt_2_2  p 
I  nil  =>  fn  ignored: tunit  =>  nil  () 
end :  blist 

•  The  concise  language  has  only  enough  type  declarations  to  uniquely  determine  the 
type  derivation,  whereas  the  formal  language  has  type  declarations  throughout  the 
code. 

e  The  concise  language  has  let  statements,  but  the  formal  language  does  not.  Since 
the  formal  language  does  not  have  polymorphism,  each  statement  of  the  form 

let  x  =  e\  in  e2  end 
can  be  interpreted  as  the  expression 


(fn  x:t  ->  t2 )  *\ 
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in  the  formal  language,  for  some  appropriate  t. 

•  The  concise  language  freely  uses  many  of  SML’s  convenient  syntactic  features  that 
are  omitted  from  the  formal  language,  such  as  let  statements  and  abstraction  operators 
that  take  cases,  destructure  tuples,  and  define  curried  functions. 

For  example,  the  concise  language  expression 

let  fun  double  f  x  3  f  (f  x) 
fun  not  true  =  false 
I  not  false  =  true 
in 

double  not  true 

end 

corresponds  to  exactly  one  formal  expression: 

(fn  double :(bool  — >  bool)  — ►  bool  — >  bool  => 

((fn  not :  bool  — »  bool  => 

double  not  (true  ())) 

(fn  b  :bool  -> 
case  b  of 

true  3>  fn  ignored:  tunit  ~>  false  () 

I  false  =>  fn  ignored:  tunit  ->  true  () 
end:  bool)) 

(fn  f: bool  —*  bool  =>  fn  xibool  f  (f  x))) 


2.4  Semantics 

This  section  describes  how  to  evaluate  closed  expressions.  We  will  call  the  result  of 
evaluation  a  value;  every  value  is  a  closed  expression  of  the  form 

v  ::=  c  v  |  (v,  ...»  v)  |  ()  j  fn  x  :t  ~>  e. 

Since  our  values  are  expressions,  we  can  apply  the  same  type  systems  to  both.  This  makes 
a  simple  notion  of  soundness  possible:  a  type  system  is  sound  if,  whenever  an  expression 
evaluates  to  a  value,  the  value  always  has  all  of  the  types  that  the  expression  has. 

There  arc  reasonable  notions  of  soundness  that  are  stronger  than  this.  We  could  follow 
[Mil78]  and  require  that  evaluation  of  a  well-typed  expression  never  “goes  wrong”,  in  the 
sense  that  semantic  errors  do  not  happen  during  evaluation.  This  would  make  the  already 
tiresome  proofs  of  soundness  in  this  thesis  even  longer,  so  we  shall  instead  stay  with  the 
weaker  notion  of  soundness. 


2.4.  SEMANTICS 


23 


Evaluation  will  require  substituting  closed  expressions  for  variables  in  expressions,  so 
we  need  to  define  substitution  before  we  define  evaluation.  Since  we  only  allow  substitution 
of  a  closed  expression  for  a  variable,  we  do  not  need  to  be  concerned  about  variable  capture. 

Definition  2.1  Substitution  of  an  expression  e  for  an  object  language  variable  x  in  an 
expression  e'  ( written  as  [e/x]e')  is  the  expression  consistent  with  the  following  rules: 

[e/*]x  =  e 

[«/*] y  =  yify  ^  * 

[e/x]fn  x:t  =>  e'  =  fn  x:t  =>  e' 

[e/x]fn  y:t  ->  e'  =  fn  y:t  =>  [e/x]e' ify  x 

[e/x]fix  x:t  =>  fn  y:u  =>  e' = 

fix  x:t  =>  fn  y:u  =>  e' 

[e/x]fix  f:t  =>  fn  x:u  =>  e'  = 

fix  /:t  =>  fn  x:u  ->  e' 

[e/x]fix  f:t  =>  fn  y:u  =>  e'  = 

fix  fit  =>  fn  yiu  =>  [e/xle' j/y  x  and  f  ^  x 
[e/x]e!  e2  =  [e/x]ei  [e/x]e2 
[e/x](elf  ...,  en)  =  ([e/*]ei,  ...»  [e/x]en) 

[«/*]()  =  0 

[e/x]elt_m_n  e'  =  elt _m_n  je/x]e' 

[e/x]c  e'  =  c  [e/x]e' 

[e/x]caso  e0  of  Ci  *>  ej  |  ...  I  Cn  ->  en  end :t — 

case  [e/x]e0  of  Cj  ->  [e/x]ej  I  ...  |  c*  =>  [e/x]e„  end:t 

For  example,  evaluating  the  expression 

(f  n  double :  bool  — >  bool  => 

(double  (fn  xibool  =>  x)  (true  ()))) 

(fn  f : bool  — >  bool  =>  fn  xibool  =>  f  (f  x)) 

would  require  computing  the  substitution 

[fn  f :  bool  — >  bool  =>  fn  xibool  =>  f  (f  x)/double] 

(double  (fn  xibool  =>  x)  (true  ())) 


which  yields 


(fn  f : bool— *  bool  =>  fn  xibool  ~>  f  (f  x)) 

(fn  xibool  ->  x) 

(true  ()). 

We  will  define  evaluation  only  for  closed  expressions.  This  is  convenient  because  it 
eliminates  the  need  for  an  environment  mapping  variables  to  values. 
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ABS-SEM: 


fn  x:t  *>  e  =»  f n  x:t  ®>  e 


APPL-SEM: 


constr-sem: 


Cl  =»  fn  x:t  *>  C3 
e2  =»  v2 
[t>i/z]e3  =»  u3 

el  e2  =►  V3 

e  =>  v 
c  c  =>  c  u 


for  some  i  we  have  e0  =>  Ci  Vi 


CASE-SEM: 


e,  Vi  =>  v 


TUPLE-SEM: 


case  eo  of  ci  =>  ci  I  ...  I  c„  =>  en  end:f=J>v 
for  t  €  1 ...  w  we  have  e,  =>  t>j 

(®1  »  •••»  ®n)  ^  (^1  *  ^n) 


ELT-SEM: 


«  =»  (”lt  •»  ”») 
elt_m_n  e  =>  vm 


FIX-SEM:  fix  f:t  =>  fn  x:u  =>  e  =» 

[fix  /:<  *>  fn  x:tt  *>  e//]fn  xiu  =>  e 


Figure  2.1:  Monomorphic  Semantics  Rules 
Our  evaluation  relation  is  written 

e  =>  v 

which  means  that  the  closed  expression  e  evaluates  to  the  value  v.  The  definition  of  the 
relation  is  in  Figure  2.1.  In  some  of  the  inference  rules,  we  use  the  notation  n . . .  m  to  mean 
the  set  of  integers  between  n  and  m. 

For  example,  if  we  use  T  to  abbreviate  the  derivation 

- - -  [tuple-sem] 

( )  =>  () 

- tt — - -  [constr-sem] 

true  ()  =»  true  () 

then  the  following  is  a  valid  evaluation,  except  to  make  the  derivation  fit  on  the  page  we 
omit  the  types  after  each  variable  binding  and  the  -sem  suffix  on  the  name  of  each  semantics 
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rule: 


(fn  x  =>  x)  =»  (fn  x  =>  x) 


[abs] 


T  T 


(fn  x  =>  x)  (true  ())  =>  (true  ()) 


[appl] 


()=>() 


[tuple] 


nil  ()  =>  nil  () 


((fn  x  =>  x)  (true  ()),  nil  ())  =>  (true  (),  nil  ()) 


cons  ((fn  x  =>  x)  (true  ()),  nil  ())  =>  cons  (true  (),  nil  ()) 


[constr] 
[tuple] 
[constr] 


The  case-sem  rule  differs  slightly  from  the  closest  analogy  available  in  our  syntax  to 
true  SML.  In  SML,  case  statements  always  evaluate  the  first  case  that  applies.  In  this 
language,  the  order  of  the  cases  makes  no  difference;  if  multiple  cases  apply,  then  this 
semantics  says  the  choice  is  made  nondeterministically.  For  example,  the  expression 

case  true  ()  of 

true  =>  fn  _  =>  true  () 

I  true  =>  fn  _  =>  false  () 
end :  bool 

evaluates  to  both  true  ()  and  false  ().  This  oddity  could  be  avoided  by  requiring  all  of 
the  constructors  appearing  in  a  case  statement  to  be  distinct,  but  we  will  have  no  need  to 
require  this. 

This  semantics  does  not  formalize  everything  one  might  want  to  say  about  evaluation.  A 
more  stringent  notion  of  soundness  would  allow  evaluation  of  well  typed  expressions  to  fail 
to  terminate,  but  it  would  not  permit  evaluation  to  get  an  error.  Unfortunately  expressions' 
that  do  not  terminate  and  expressions  that  get  an  error  are  not  distinguished  from  each  other 
by  our  semantics.  Both  kinds  of  expression  have  no  value. 

This  could  be  repaired  by  adding  a  new  value  “wrong”  along  with  rules  that  ensure  that 
code  with  a  type  error  evaluates  to  “wrong”.  As  mentioned  earlier,  we  will  not  take  this 
route  because  of  the  added  tedium. 


2.5  ML  Typing 

The  system  described  in  this  section  checks  that  the  ML  types  embedded  in  an  expression 
are  consistent  with  each  other,  and  it  determines  an  ML  type  for  the  expression  as  a  whole. 
The  ML  type  of  an  expression  depends  on  the  assumptions  we  make  about  the  ML  types  of 
constructors  used  in  the  expression,  so  we  shall  discuss  that  first. 

If  c  is  a  value  constructor,  we  say  that  c  maps  values  of  type  t  to  elements  of  the  datatype 
tc  by  writing 

def  *  i 

c  ::  t  <—+  tc. 

For  example,  the  effect  of  the  SML  datatype  declaration 
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datatype  bliat  -  nil  of  tunit  |  cons  of  bool  *  bliat 

on  the  SML  environment  would  be  analogous  to  adding  these  assumptions  to  the  environ¬ 
ment: 

nil  If  limit  *  bliat 
cons  If  bool  *  bliat  *— ►  bliat 

The  examples  in  this  chapter  will  also  make  these  assumptions: 

true  If  tunit  <— »  bool 
false  f?  tunit  t—*  bool 

In  general,  for  a  type  system  that  uses  assumptions  about  value  constructors  to  make 
sense,  we  need  the  assumptions  to  be  consistent  in  certain  ways.  For  the  type  system 
described  in  this  section,  all  we  need  to  know  is  that  we  have  exactly  one  assumption  about 
each  constructor: 

Assumption  2.2  (Constructors  have  Unique  ML  Types)  For  each  c,  there  are  unique  t 
and  tc  such  that 


The  ML  type  of  an  expression  depends  on  the  ML  types  we  assign  to  the  free  variables 
appearing  in  the  expression,  so  our  typing  relation  will  describe  the  type  of  an  expression 
given  a  partial  function  VMVM  from  variables  to  ML  types. 

The  name  VM  is  an  example  of  a  naming  convention  that  will  be  used  for  all  of  the 
partial  functions  used  as  environments  in  this  thesis.  Each  name  has  two  letters.  The  first 
letter  stands  for  the  domain  (V  stands  for  “variable”)  and  the  second  letter  stands  for  the 
codomain  (M  stands  for  “ML  type”).  In  later  chapters,  M  will  sometimes  stand  for  “ML 
type  scheme”,  but  since  the  formal  language  is  monomorphic,  it  just  stands  for  “ML  type” 
here. 

We  use  the  notation  VM[i  :=  t]  to  mean  the  partial  map  identical  to  VM  everywhere 
except  at  x,  which  it  maps  to  t.  The  notation  •  means  the  partial  map  that  is  undefined 
everywhere. 

The  ML  typing  relation  is  written  as 

VM  F  e  ::  t 

which  means  that  assuming  that  all  free  variables  x  in  e  have  the  type  VM(x),  then  e  has 
the  ML  type  t.  The  definition  of  this  relation  is  in  Figure  2.2.  These  rules  are  similar  to 
the  rules  in  Mini-ML  [CDDK86],  except  we  have  no  polymorphism  and  we  separate  the 
operator  for  destructuring  tuples  from  the  operator  for  forming  abstractions. 

If  this  type  system  is  sound,  then  we  would  expect  that  a  closed  expression  has  a  type 
and  it  evaluates  to  a  value  then  the  value  has  the  same  type.  We  can  formally  state  this  as 
follows: 
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VAR-VALID: 


VM(*)  =  t 
VM  h  x  ::  t 


ABS-VALID: 


appl-vaud: 


constr-valid: 


VM[a;  :=  ti]  h  e  ::  t2 
VM  h  (fn  x\t\  ->  e)\:t\-+t2 


VM  I-  et  ::  t2  -+tx  VM  h  e2  ::  t2 
VM  h  ei  e2  ::  ti 

c  /  t— >  tc  VM  I -  e  ::  t 
VM  he  e  ::  tc 


CASE-VALID: 


VM  h  eo  ::  tc 

for  all  t  we  have  c*  If  ^  «-»  tc 
for  all  i  we  have  VM  h  e< ::  t*  — ►  u 


tuple-valid: 


ELT-valid: 


FIX-VALID: 


VM  I- (case  ^  of  C|  =>  ei  I  ...  I  c*  =>  en  end:u)  ::  u 

for  all  i  we  have  VM  h  ::  L 
VMh(ei,  ...,  em)  ::ti*...*tm 

VM  h  e  ::  f)  *  . . .  *  t„ 


VM  h  elt _m_n  e  ::  tm 

VM[/  :=  1 1  — >  t2]  h  (fn  g : 1 1  =>  e)  ::  1 1  — » t2 
VM  h  (fix  f'.t\  —>t2  =>  fn  x:t\  =>  e)  ::  <1  — *t2 


Figure  2.2:  Monomorphic  ML  Typing  Rules 

Fact  23  (ML  Type  Soundness)  If  •  F  e  ::  t  and  e  =>  v  then  •  h  v  ::  t. 

We  will  not  prove  this.  A  partially  mechanically  verified  proof  of  this  theorem  for  a 
similar  language  is  in  [MP91]. 

We  intend  our  ML  type  system  to  be  an  unambiguous  framework  that  supports  the 
refinement  type  system.  The  following  theorem  states  that  it  is  unambiguous.  Theorem 
2.54  (Inferred  Types  Refine)  on  page  68  states  in  what  sense  the  refinement  type  system  is 
supported  by  the  ML  type  system. 

Lemma  2.4  (Unique  Inferred  ML  Types)  //VM  he::t  and  VM  h  e  ::  t'  then  t  =  t'. 
Proof:  By  straightforward  induction  on  e. 
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Case:  e  =  x 


Then  the  last  inference  in  both  of  our  hypotheses  is  var- valid,  with  the 


premises  VM(as)  =  t  and  VM(s)  =  t'.  Thus  t  =  t'. 


Case:  e-in  zit\  =>  e'  Then  the  last  inference  in  both  of  our  hypotheses  is  ABS-VAUD. 

Since  the  ML  type  ii  is  explicit  in  the  syntax,  we  must  have  t  =  t\-*t 2  and  t*  =  t\  -*  tj. 
The  premises  of  the  two  uses  of  abs-vajlid  must  be 


VM[*  :=  tj]  H  e' ::  t2 


and 


VM[x  :=  tj]  h  e' ::  t^. 

The  induction  hypothesis  gives  ti  =  t'2,so  we  must  have  t  =  t‘. 


Case:  t  —  ex  «2 


Then  the  last  inference  in  our  hypotheses  must  be  APPL- VALID  with  the 
VM  h  ej  ::  ti  — ►  t 

VMhe, 

among  others.  The  induction  hypothesis  applied  to  these  gives  *2 -+ 1  =  which 

implies  t  »  t'. 


premises 

and 


Case:  e  =  c  e 


Then  the  last  inference  in  our  hypotheses  must  be  constr- VALID  with  the 


premises 


and 


del  . 
c  ::#<->« 


dcf  (  .  i 

c  ::  u  «— » fc  , 


among  others,  where  t  =  tc  and  t'  —  ic'.  Assumption  2.2  (Constructors  have  Unique  ML 
Types)  on  page  26  gives  ic  —  tc',  which  implies  t  =  t'. 


Case:  e  =  case  eo  of  q  =»>  ej  |  ...  1  c*  <=>  e„  end.-u 


The  last  inference  of  both  of  our  hypotheses  must  be  case- valid,  which  immediately  gives 
t  =  u  and  t*  =  tt,  so  t  =  ?. 


Case:  e  =  (ei ,  . . .,  en)  Then  the  last  inference  in  the  derivation  of  each  of  our  hy¬ 


potheses  must  be  tuple- valid  with  the  premises 

for  all  t  we  have  VM  h  e< :: 


P.3 


and 


for  all  *  we  have  VM  H  e» ::  t\ 


P.4 
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where  t  =  t\  * . . .  *  t*.  and  t'  =  t\  * . . .  *  tfn.  Our  induction  hypothesis  gives  =  t\  for  all 
t,  so  t  =  ?. 

Case:  e  =  »lt  _m_n  e  *  Then  the  last  inference  in  die  derivation  of  each  of  our  conclu¬ 
sions  must  be  elt- VALID  with  the  premises 

VM  I-  e' ::  fj  * . . .  * 
and 

VM  h  *...*£ 

where  t  =  tw  and  f  Our  induction  hypothesis  gives  t\  * . . .  *  tn  s=  t\  * . . .  *  so 
we  must  have  <  =  t'. 

Then  the  last  inference  in  the  derivation 

This  immediately  gives  t  =  -» *2  and 

□ 

If  an  expression  has  an  ML  type,  then  all  of  its  free  variables  must  be  bound  to  an 
ML  type  in  the  environment  This  will  be  important  later  on  when  we  are  proving  things 
about  the  refinement  type  system  because  the  refinement  type  rule  for  case  statements  has 
a  premise  requiring  the  case  statement  to  have  an  ML  type.  To  put  it  formally. 

Fact  2jS  (ML  Free  Variables  Bound)  If  VM  e  ::  t  and  z  is  free  in  e,  then  VM(x)  is 
defined. 

Proof  of  this  would  be  by  induction  on  the  derivation  of  VM  1 -  e ::  t. 

One  step  along  the  path  to  proving  Fact  2.3  (ML  Type  Soundness)  on  page  27  is 
showing  that  there  is  a  natural  kind  of  substitution  on  ML  type  derivations  that  preserves 
soundness.  We  will  use  this  once  in  Lemma  2.70  (Value  Substitution)  on  page  93,  which  is 
the  refinement  type  analogue  of  this  fact.  The  use  is  in  the  Case-type  case  of  that  lemma. 

Fact  2.6  (ML  Value  Substitution)  If  VM  1-  e\  ::  i\  and  VM[x  :=  h  ez  ::  t2  then 
VM  h  [ei/x]ei :  h,. 

Proof  of  this  would  be  a  straightforward  induction  on  the  derivation  of  VM[*  :=  *i]  h  e*  :: 
tz- 


2.6  Monomorphic  Refinement  Types 

Now  that  we  have  given  our  version  of  die  ML  type  system,  we  can  give  an  analogous 
description  of  refinement  types  for  the  same  expressions.  We  shall  use  r,  k,  and  p  as 
metavariables  standing  for  refinement  types. 


Case:  e  =  fix  ~>  in  zit\  =>  e' 

of  each  of  our  conclusions  must  be  FIX- VALID. 
t!  =  ti  -►  <2,  which  implies  t  =  t'. 
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Syntactically,  refinement  types  have  an  intersection  operator  “A”.  This  is  the  only 
difference  in  structure  between  the  syntax  for  refinement  types  and  the  syntax  for  ML  types, 
so  we  can  define  the  syntax  for  refinement  types  with  the  grammar 

r  ::=  r  A  r  |  r  — »r|rc|r*...*r|  runit. 

Once  again  we  have  a  special  name  for  the  empty  tuple  type;  this  time  it  is  runit.  Because 
we  give  different  names  to  tunit  and  runit,  inspecting  a  type  tells  us  immediately  whether 
it  is  an  ML  type  or  a  refinement  type. 


In  our  concrete  syntax  we  shall  adopt  the  convention  that  — >  binds  tighter  than  A.  This 
makes  it  easy  to  write  types  consisting  of  an  intersection  of  many  arrow  types.  Since 
the  principal  type  of  each  function  has  this  form,  being  able  to  write  these  concisely  is 
convenient.  For  instance,  the  type  of  boolean  negation  is  (tt  — ►  ff)  A  (ff  — >  tt),  which  we 
can  write  as  tt  — *  ff  A  ff  — >  tt. 

The  set  of  refinement  types  an  expression  may  have  depends  on  its  ML  type.  For 
instance,  an  expression  with  ML  type  bool  bool  may  have  refinement  type  tt  — >  tt  or 
T ieoi  —>ff,  but  not  tt.  We  write  this  as 

tt  —*tt  d  bool  — *  bool 
T  ),00i  — » ff  d  bool  — >  bool 


but  not 


tt  d  bool  —*  bool. 

The  assertion  rdf  can  be  read  aloud  as  “r  refines  i”;  hence  the  name  “refinement  types”. 
We  will  call  a  refinement  type  that  refines  no  ML  type  “malformed”. 


Before  we  can  formally  define  the  d  relation  between  refinement  types  and  ML  types, 
we  have  to  make  some  assumptions  about  which  refinement  type  constructors  refine  which 
ML  type  constructors.  We  shall  write  the  assumption  that  a  refinement  type  constructor  rc 
refines  an  ML  type  constructor  tc  as 

def 

rc  d  tc. 


For  example,  after  we  formally  define  d,  our  derivation  of  T  — ♦  ff  d  bool 

use  the  assumptions 

def 

T  iggl  d  bOOl 


and 

def 

ff  d  bool. 

The  examples  below  will  also  use  these  assumptions: 

def 

tt  d  bool 

def 

lioofd  bool 


bool  will 


For  our  soundness  proof  to  go  through,  we  will  need  the  d  relation  to  be  well-behaved 
in  the  following  sense: 
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and-ref: 


riCt  r2  C  t 
T\  A  r2Ct 


ARROW-REF: 


ri  c:  ti  r2  c  e2 

Tj  -+T2  C  >  t2 


def 

rcon-ref:  _  !=Jf 

rc  [I  tc 


TUPLE-REF: 


for  z  in  1 ...  n  we  have  r,  C  U 
rl  *  •  •  •  *  rn  (Z  t\  *  . . .  *  tn 


Figure  2.3:  Monomorphic  Refinement  Rules 

Assumption  2.7  (Unique  Predefined  Refinements)  For  all  rc  there  is  a  unique  tc  such 

def 

that  rc  (Z  tc. 

Also,  for  there  to  be  any  hope  of  manipulating  refinement  types  with  an  algorithm,  the 
set  of  refinements  of  any  ML  type  constructor  must  be  finite: 


Assumption  2.8  (Finite  Predefined  Refinements)  For  all  tc,  the  set  {rc  \  rc  □  rc}  is 
finite. 

We  formally  define  the  C  relation  in  Figure  2.3. 

TUPLE-REF  implies  runit  C  tunit  because  we  can  choose  n  =  0,  and  runit  and  tunit 
are  our  names  for  the  empty  tuples  of  refinement  types  and  ML  types,  respectively. 

Refinement  types  that  refine  some  ML  type  are  generally  easier  to  reason  about  than 
refinement  types  that  do  not: 

Definition  2.9  (Well-formed  Refinement  Type)  We  say  that  a  refinement  type  r  is  wcd- 
formed  if  there  is  an  ML  type  t  such  that  r  \zt.  Otherwise  we  say  it  is  ill-formed. 

From  the  rule  defining  C,  it  follows  that  each  refinement  type  refines  at  most  one  ML 
type.  Stating  this  formally, 

Lemma  2.10  (Unique  ML  types)  7/r  c  t  and  rc  u  then  t  =  u. 

The  proof  of  this  is  straightforward. 

Proof:  By  induction  on  r. 
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Case:  r  =  k  A  p  The  only  way  to  derive  r  C  t  is  to  use  AND-REF  where  one  of  the 

premises  is  k  C  t.  Similarly,  the  only  way  to  derive  r  c  u  is  to  use  AND-REF  where  one 
of  the  premises  is  k  c  u.  Applying  the  induction  hypothesis  to  these  two  premises  gives 
t  =  u,  which  is  our  conclusion. 

Case:  r  =  rc  Assumption  2.7  (Unique  Predefined  Refinements)  on  page  31  gives  our 
conclusion  directly. 

Case:  r  =  *  ...  *  rn  We  can  only  derive  r  d  t  by  using  tuple-ref.  Thus  t  must  have 

the  form  t\*  and  from  the  premises  of  tuple-ref  we  know 

for  i  between  1  and  n  we  have  Ti  C 
Similarly,  r  C  u  tells  us  that  u  has  the  from  u\  *  ...*un  and 

for  i  between  1  and  n  we  have  r;  C  Uj. 

Using  the  induction  hypothesis  gives 

for  i  between  1  and  n  we  have  U  =  Ui. 


Thus  t  =  u. 

Case:  r  —  runit  Then  the  only  way  to  derive  our  hypotheses  is  by  using  UNIT-REF,  and 
t  =  u  =  tuv.it. 

Case:  r  —  ri  — *  rz  Then  the  last  premise  of  the  derivation  of  r  c  t  must  be  ARROW-REF, 

so  t  must  have  the  form  tx  — >  t2  and  the  premises  of  arrow-ref  must  be  n  □  t\  and 
i*2  C  <2-  Similarly,  r  C  u  tells  us  that  u  has  the  form  u\  — >  u2  and  r,  c  and  r2  C  u2. 
The  induction  hypothesis  tells  us  that  f  i  =  u\  and  t2  =  u2,  so  t  =  u.  □ 

Since  each  refinement  type  refines  at  most  one  ML  type,  we  can  define  a  partial  function 
that  maps  each  refinement  type  to  the  corresponding  ML  type,  if  there  is  one. 


Definition  2.11  Ifr\zt  then  we  say  t  =  rtom(r).  If  there  is  no  t  such  that  r  C  t,  then 
rtom(r)  is  undefined. 


The  name  rtom  stands  for  “Refinement  to  ML”.  We  extend  this  in  the  natural  way  to 
work  on  environments:  rtom(VM)(®)  =  rtom(VM(x)). 

As  one  would  expect,  if  we  know  which  ML  type  is  refined  by  a  refinement  type,  that 
heaviiy  constrains  the  form  of  the  refinement  type.  For  example,  we  have 

Fact  2.12  (T\iple  Refines)  Ifr  UL  t{  *  . . .  *  th  then  r  has  the  form 

7*11  *  ...  *  T*fci  A  ...  A  rln  *  ...  *  rhn. 
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Proof  of  this  would  be  a  trivial  induction  on  the  derivation  of  r  c  fi  * . . .  *  We  will  use 
this  in  Lemma  2.26  (Tuple  Subtyping)  on  page  42. 


2.6.1  Subtyping 

If  two  refinement  types  refine  the  same  ML  type,  then  it  makes  sense  to  compare  them.  Our 
comparison  operator  is  written  <.  For  instance,  in  the  presence  of  reasonable  assumptions 
about  our  refinement  type  constructors,  the  following  assertions  are  true: 


tt  <  Tfc*,, 

i -4,0/ <  ttAff 

(tt*ff)A(ff*tt)  <  (Xiooi  *  1M) 
tt  —*ff  A  ff-+tt<  tt-+Tiool 

and  these  assertions  are  false: 

8  <  tt 

tt-+ff  <ff-+tt. 

The  rules  defining  <  must  take  into  account  some  assumptions  about  how  the  refinement 
type  constructors  behave.  We  need  to  know  that  some  refinement  type  constructors  are 
subtypes  of  others,  which  we  shall  write  as 


def 

rcj  <  rci. 

We  also  need  to  be  able  to  compute  intersections  of  refinement  type  constructors,  if  they 

def 

both  refine  the  same  ML  type  constructor.  We  write  this  as  a  partial  binary  operation  A  on 
refinement  type  constructors.  For  example,  the  definition  of  <  we  will  give  below  allows 
us  to  derive 

tt  >  tt  AT  bool  *  8  —  -1-  bool  *  -L  bool , 

and  the  derivation  uses  these  assumptions: 


def 

Uool<  tt 
def 

-L  bool  5;  T  boot 
def  def 
tt  A  8  <±bool 


For  our  definition  of  subtyping  to  make  sense,  we  need  <  and  A  to  be  consistent  in 

def 

certain  ways.  First  we  need  transitivity  and  reflexivity  of  < : 

def  def 

Assumption  2.13  (reflex- <)  For  all  rc  we  have  re  <  rc. 
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def  def  def  def 

Assumption  2.14  (trans-<)  Ifrc\  <  rci  and  rcz  <  rc$  then  rc\  <  rc3- 

If  two  refinement  type  constructors  are  comparable,  they  must  refine  the  same  ML  type 
constructor: 


def  def  def  def 

Assumption  2.15  (Rennes  <)  Ifrc  <  kc  then  rc  C  tc  if  and  only  ifkc  C  tc. 


We  need  to  know  A  is  defined  for  refinements  of  the  same  ML  type  constructor,  and  it 
is  a  greatest  lower  bound  in  the  set  of  those  refinements: 


def  def  def  def 

Assumption  2.16  ( A -defined)  If  rc  C  tc  and  kc  C  tc  then  rc  A  kc  is  defined. 


def  def  def  def  def  def 

Assumption  2.17  ( A  Elim)  Ifrc  A  kc  is  defined,  then  rc  A  kc  <  rc  and  rc  A  kc  <  kc. 


def  def  def  def  def 

/sumption  2.18  (and-intro-<)  If  rc  <  kc  and  rc  <  pc  then  rc  <  {kc  A  pc). 

Our  subtyping  operator  <  is  defined  by  the  rules  in  Figure  2.4.  Several  of  these  rules 
need  to  be  explained: 

Since  runit  is  our  name  for  the  empty  tuple,  we  interpret  the  rule  for  dealing  with  tuples 
so  they  apply  to  runit  also. 

Some  of  the  rules  resemble  each  other.  The  rules  ARROW-SUB,  TUPLE-SUB,  and  RCON- 
SUB  are  similar,  as  are  arrow- and-elim-sub,  tuple-and-elim-sub,  and  rcon-and-elim- 
SUB.  In  Chapter  5  we  will  change  the  syntax  for  refinement  types  so  that  arrows,  tuples,  and 
monomorphic  refinement  type  constructors  are  all  a  special  case  of  polymorphic  refinement 
type  constructors.  After  we  do  that,  each  triplet  of  similar  rules  will  collapse  to  one  rule. 

The  rule  arrow-sub  is  conventional  for  systems  with  subtypes,  although  it  is  often 
surprising  to  the  uninitiated.  As  the  type  on  the  right  side  of  the  arrow  gets  larger,  the 
entire  type  gets  larger.  However,  as  the  type  on  the  left  side  gets  larger,  the  entire  type 
gets  smaller.  Another  way  to  say  this  is  that  arrow  is  contravariant  in  its  first  argument  and 
covariant  in  its  second  argument. 

To  understand  this  it  helps  to  think  of  refinement  types  as  sets  and  to  read  “<”  as  subset. 
An  arrow  type  ri  — >  r2  means  the  set  of  all  functions  that  map  all  elements  of  the  set  r\  to 
elements  of  r2.  If  inf  is  the  set  of  all  integers  and  ev  is  the  set  of  all  even  integers,  then  the 
following  subtype  relations  are  true  in  our  model: 


ev<int 

ev  — ♦  ev<ev  — ►  inf 
inf  — ►  ev<ev  — ►  ev 
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SELF-SUB: 


r  C  t 
t  <  r 


AND-ELIM-R-SUB: 


r  □  t  kdt 
r  A  k  <  r 


AND-ELIM-L-SUB: 


AND-INTRO-SUB: 


r  C  t  k\Zt 

r  A  k  <  k 

r  <  k\  r  <  fcj 

r  <  k\  A  fa 


TRANS-SUB: 


r  <  p  p  <  k 
r  <  k 


ARROW-SUB: 


ARROW-AND-ELIM-SUB: 


k\  <  T\  r2  <  kz 
ri  — *  t2  <  k\  — ►  &2 

_ rt  -»(r2  A  r3)  C  t _ 

— *■  *2  A  rj  — ♦ r3  <  r!  — >(r2  A  r3) 


rcon-sub: 


dcf 

rc  <  kc 
rc  <  kc 


rcon- and-elim-sub: 


def 

rc\  A  tv2  \Z  t 

def 

rcj  A  rc2  <  rci  A  rc2 


TUPLE-SUB: 


for  all  i  we  have  <  kj 
r\  *  ...  *  Tn  <  k\  *  ...  *  kn 


TUPLE- AND-ELIM-SUB: 


_ (rt  Ar()*...*(rwAr|,)Cl 

(rx  *  ...  *  rn)  A  (r{  *  ...  *  r'n)  <  (r,  ArJ)*. 


*  (rn  A  r'n) 


Figure  2.4:  Monomorphic  Subtyping  Rules 
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Thus  the  intuitive  model  is  consistent  with  the  inference  rule. 

Following  [Pie9 1  b],  we  use  subtyping  inference  rules  to  express  the  fact  that  intersection 
is  a  greatest  lower  bound.  The  rules  and-elim-l-sub  and  and-elim-R-sub  ensure  that 
intersection  is  a  lower  bound  and  and-CNTRO-sub  guarantees  that  it  is  a  greatest  lower 
bound.  Since  intersection  is  a  greatest  lower  bound,  it  is  commutative,  associative,  and 
monotone  in  both  arguments.  The  usual  proofs  that  any  greatest  lower  bound  has  these 
properties  translate  directly  into  uses  of  the  inference  rules.  For  example,  here  is  a  proof 
that  intersection  is  monotone  in  its  first  argument: 

Lemma  2.19  Ifr\  <  r2  and  rx  A  r2  A  r3  C  t,  then  ri  A  r3  <  r2  A  r3. 


Proof:  The  only  way  to  derive  rx  A  r2  A  r3  O  t  is  by  repeatedly  using  AND-REF,  so  we  must 
have  r\  \zt  and  r2ct  and  r3  c  t.  The  rule  and-elim-R-sub  gives  rj  A  r3  <  n.  Applying 
TRANS-SUB  to  this  and  our  hypothesis  gives  r(  A  r3  <  r2.  The  rule  and-elim-l-sub  gives 
t*i  Ar3  <  r3.  The  previous  two  assertions  and  AND-INTRO-SUB  give  ri  A  r3  <  r2  A  r3,  which 
is  what  we  wanted  to  show.  □ 

Once  we  have  a  subtying  relation,  we  can  define  a  natural  notion  of  equivalence: 

Definition  2.20  We  say  that  rx  is  equivalent  to  r2,  or  in  symbols  r,  =  r2,  if  rx  <  r2  and 
r2  <  r\. 


This  relation  is  an  equivalence  relation  on  the  refinements  of  any  ML  type,  but  it  is  only  a 
partial  equivalence  relation  on  refinement  types  as  a  whole  because  some  refinement  types 
refine  no  ML  type.  For  example,  the  refinement  type  tt  A  tt—*  it  is  not  equivalent  to  itself 
according  to  this  definition. 

The  subtyping  rules  in  Figure  2.4  ensure  that  the  types  involved  are  well  behaved  in  the 
following  sense: 

Theorem  2.21  (Subtypes  Refine)  If  r  <  k,  then  there  is  a  unique  ML  type  t  such  that 
rCt  and  k  C  t. 


Proof:  By  Lemma  2.10  (Unique  ML  Types)  on  page  31,  there  is  at  most  one  t  such  that 
ret  and  k  C  t,  so  all  we  need  to  show  here  is  that  there  is  at  least  one  such  t.  We  do  this 
by  induction  on  the  derivation  of  r  <  k. 


Case:  SELF-SUB 


Case:  AND-ELIM-R-SUB 


must  be 


Then  r  =  k  and  the  premise  of  SELF-SUB  gives  a  t  such  that  rd. 

Then  r  has  the  form  k  A  p  and  the  premises  of  and-ELIM-r-sub 
kct  (2.1) 
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(2.2) 

(2.3) 


Case:  AND-INTRO-SUB  Then  k  has  the  form  kx  A  hi  and  the  premises  of  and-intro-SUB 
must  be 


r  <  k\ 

(2.4) 

and 

T  <  &2 

(2.5) 

Using  the  induction  hypothesis  on  (2.4)  gives  a  t  such  that 

r  C  t 

(2.6) 

and 

kx  c  t. 

(2.7) 

Using  the  induction  hypothesis  on  (2.5)  gives  a  u  such  that 

r  C  it 

(2-8). 

and 

ki  C  u 

(2.9) 

Lemma  2.10  (Unique  ML  Types)  on  page  31  applied  to  (2.6)  and  (2.8)  gives  t  =  u,  so  we 
can  use  and-ref  to  combine  (2.7)  and  (2.9)  to  get 


kx  A  *2  C  t. 

This  and  (2.6)  are  our  conclusions. 

Case:  TRANS-SUB  Then  the  premises  of  trans-SUB  are  r  <  p  and  p  <  k.  Applying  the 
induction  hypothesis  to  both  of  these  gives  t  and  u  such  that  all  of  the  following  hold: 

r  O  t 
p  C  t 

pCtt 

k[Zu. 

Unique  ML  Types  applied  to  the  middle  two  gives  us  t  =  u,  so  the  first  and  the  last  are 
our  conclusions. 
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Case:  rcon-sub 


def 


Then  r  =  rc  and  k  =  kc  and  the  premise  of  RCON-SUB  is  re  <  kc. 


def 


Assumption  2.7  (Unique  Predefined  Refinements)  on  page  31  gives  a  tc  such  that  rc  c  tc. 

def  def  def 

By  Assumption  2.15  (Refines  <)  on  page  34  and  rc  <  kc  we  have  kc  C  tc.  Rcon-ref 
gives  rc  o  tc  and  kc  C  tc,  which  are  our  conclusions. 


Case:  rcon-and-elim-sub 


def 


Then  r  =  rc\  A  rc2  and  k  =  rci  A  rc2.  The  premise  of 


RCON-AND-ELIM-SUB  IS 


def 

rci  A  rc2  C  t. 


(2.10) 

def  def 

By  Assumption  2.17  (  A  Elim)  on  page  34  and  Assumption  2.15  (Refines  <)  on  page  34, 

def  def  def 

rei  C  t  and  nc2  C  t.  Because  “Cl”  only  relates  refinement  type  constructors  to  ML 

def 

type  constructors,  t  must  have  the  form  tc.  By  Assumption  2.17  (A  Elim)  on  page  34, 

def  def  def 

we  know  rc\  A  rc2  <  rc By  Assumption  2.15  (Refines  <)  on  page  34,  it  follows  that 

def  def 

rc\  A  rc2  \Z  tc.  By  RCON-SUB, 

def 

rci  A  rc2  □  tc. 

This  and  (2.10)  are  our  conclusions. 

Then  r  =  rt  ~*r2  and  k  =  k\  — >  k2  and  the  premises  of  arrow-sub 

fc,  <  r{ 


Case:  arrow-sub 


are 


and 

r2  <  fc2. 

Applying  the  induction  hypothesis  to  both  of  these  gives  t\  and  f2  such  that: 

kx  C  t\ 
ri  Cfi 
r2  C  h 
kz  C  t2. 

Applying  arrow-ref  to  these  gives 


and 

which  are  our  conclusions. 


Case:  arrow-and-elim-sub 


n  -►  r2  c  f  1  -» t2 
k\  — *  k^  C  1 1  — *  t2 , 

Then  r  =  ri  —*{r2  A  r3)  and  k  =  rx  — >  r2  A  rt  — >  r3.  The 


premise  of  ARROW-AND-ELIM-SUB  is 


r\  ->(r2  A  r3)  C  t. 


(2.11) 
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The  last  inferences  of  the  derivation  of  this  must  be  ARROW-REF  and  and-REF,  so  we  must 
have 

t  =  t,  ->  t2 
r\  C  t{ 
r2  C  t2 
rj  C  t2 

Applying  arrow-ref  and  AND-REF  to  these  in  a  different  order  gives 

r(  — >  r2  A  r}  — >  r3  O  tx  — »  t2 


This  and  (2.1 1)  are  our  conclusions. 


Case:  tuple-SUB 


Thenr  =  r\  *. .  .*rn  and  k  =  k{  ,*kn  and  the  premise  of  TUPLE-SUB 


is  ri  <  ki  for  all  i  between  1  and  n.  Applying  the  induction  hypothesis  to  this  gives,  for 
each  i  between  1  and  n,  a  U  such  that  i\  c  and  C  U.  Tuple-ref  gives 


T\  *  ...  *  rn  C.  ti  *  ...  *  tn 


and 


k\  *  ...  *  kn  Cl  t\  *  . . .  *  tni 

which  are  our  conclusions.  If  we  take  n  =  0,  this  conclusion  tells  us  runit  C  tunit ,  which 
is  true  and  unremarkable. 


Case:  tuple- and-elim-sub 


Then  r  =  * . . .  *  rn)  A  (r{  * . . .  *  r'n)  and  k  =  (ri  A  r\ )  * 


. .  *  (r„  A  r^).  The  premise  of  TUPLE- AND-ELIM-SUB  is 

(ri  A  r|)  *  ...  *  (rn  A  r^)  C  t. 


(2.12) 


The  only  way  to  derive  this  is  with  TUPLE-REF,  so  we  must  have  t  =  t\  *  . . .  *  tn  and 


(ri  A  r')  C  ti 


for  i  between  1  and  n.  Each  of  these  assumptions  must  follow  from  and-REF,  so  for  all  i 
we  must  have 

Ti  C  ti 


and 

r'i  c  U. 

Applying  TUPLE- REF  to  these  gives 


and 


r\  * 


*rnCt. 
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Applying  AND-REF  to  these  gives 

(ri  A(rJ  *...*r'n)  C  t. 


This  and  (2. 12)  are  our  conclusions.  If  we  taken  =  0,  our  conclusions  are  runit  A  runit  C  t 
and  rum!  C  t,  both  of  which  are  true  and  uninteresting.  □ 

Some  uses  of  A  are  inessential.  We  do  not  need  to  be  able  to  take  intersections  of  tuples 
or  of  refinement  type  constructors;  every  intersection  of  tuples  can  be  simplified  to  a  tuple 
of  intersections,  and  every  intersection  of  refinement  type  constructors  can  be  simplified  to 
a  refinement  type  constructor.  These  simplifications  are  necessary  in  many  places  in  the 
proofs  appearing  later  in  this  chapter,  so  we  will  prove  that  they  are  valid  now. 

For  example, 

( tt  *  T bool)  A  (ff  *  ff)  =  J_4oo,  *ff 
and 

tt  A  =  tt. 


We  will  prove  that  simplifications  like  this  are  possible  in  the  general  case. 


Lemma  2.22  (T\iple Intersection)  lfr\  *  ...*rnCt  and  kx  *  . . .  *  fc„  c  t  then 
(r|  *  ...  *rn)  A(k\  *  ...  *  kn)  =  (ti  A  k\)  *  . . .  *  (rn  A  kn). 


Proof  of  (rt  *  . . .  *  rn)  A  (&i  *  ...  *  kn)  <  (rj  A  fcj )  *  . . .  *  (rn  A  kn):  Immediate  from 
TUPLE- AND- ELIM-SUB. 

Proof  of  (t*i  A  fci )  *  . . .  *  (r„  A  kn)  <  {r\*  ...*  rn)  A  (k\*  ...*  kn ):  Use  AND-ELIM-L-SUB 
and  AND-ELIM-R-SUB  to  get 

for  h  in  1 ...  n  we  have  r>,  f\kh<  rh 


and 


Then  TUPLE-SUB  gives 


and 


for  h  in  1 ...  n  we  have  rh  A  kh  <  kh- 


(r\  A  k\)  *  ...  *  (rn  A  kn)  <  ri  *  . . .  *  r„ 


(rx  Aki)  *  ...  *  (rn  A  kn)  <  ki  *  ...  *  kn. 
Finally  AND-INTRO-SUB  gives 

{r\  Ak{)*  ...*(rnAkn)  <{r:*  ...*  rn)  A  (k\  * 

which  is  our  conclusion. 


•  *  K), 
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In  a  moment,  we  will  present  a  simple  algorithm  that  simplifies  tuple  refinement  types. 
Since  this  is  the  first  algorithm  we  present  at  the  meta-level  (that  is,  it  manipulates  refinement 
types  as  objects),  we  need  to  describe  the  notation  we  will  use  for  these  algorithms  first. 

The  notation  is  basically  Standard  ML,  except  we  allow  free  use  of  set  notation  and 
ellipses  “. . .”,  provided  the  meaning  is  unambiguous.  Since  sets  in  mathematics  and  records 
in  SML  are  both  written  with  braces,  we  must  give  up  one  or  the  other  to  avoid  ambiguity; 
we  give  up  records.  Our  meta-level  algorithms  will  also  occasionally  lapse  into  English  or 
mathematics.  As  an  example,  we  can  give  the  simple  algorithm  for  simplifying  tuples: 

fun  tuplesimp  (t*h  * ...  *  r^i  A  ...  A  rin  *  ...  *  r^n)  = 

(rn  A  ...  A  rln)  *  ...  *  ( rhi  A  ...  A  rhn) 

This  algorithm  uses  SML’s  destructuring  convention  with  ellipses  to  simultaneously  bind  h 
and  n  to  nonnegative  integers  and  the  variables  rjj  to  refinement  types  for  i  between  1  and 
h  and  j  between  1  and  n.  Then  it  uses  ellipses  again  to  construct  a  refinement  type  that  is  a 
rearranged  form  of  the  given  refinement  type. 

This  notation  has  advantages  and  disadvantages.  Since  it  is  based  on  a  real  program¬ 
ming  language,  it  tends  to  remain  comprehensible  as  the  algorithms  we  describe  get  more 
complex.  Since  it  is  based  on  Standard  ML,  it  is  likely  to  be  understandable  to  people 
reading  this  thesis.  However,  basing  the  metalanguage  on  SML  also  invites  confusion 
between  the  metalanguage  and  the  object  language,  and  this  form  of  metalanguage  is  not 
necessary  for  simple  algorithms  like  tuplesimp  that  will  appear  early  in  this  chapter.  On 
the  whole,  the  advantages  seem  more  important,  and  we  will  use  this  notation  throughout. 

By  repeatedly  using  Lemma  2.22  (Tuple  Intersection)  on  page  40,  it  is  easy  to  show 
that  tuplesimp  is  sound: 

Fact  2.23  (Tiiplesimp  Sound)  Ifr{Zti*...*th  then  tuplesimp  r  terminates  and  has 
the  form  *  ...  *rh,  and  r  =  tuplesimp  r. 

We  can  show  similar  properties  for  refinements  of  any  ML  type  constructor,  and  a 
similar  simplification  procedure  emerges. 

Lemma  2.24  (Refinement  Constructor  Intersection)  lfrc\  A  ...  A  rcn  d  t  then 

def  def 

rc  1  A  . . .  A  rcn  =  rc\  A  ...  A  rcn. 

Proof:  By  repeated  use  of  rcon-and-EUM-SUB, 

def  def 

rc !  A  ...  A  rcn  <  rc\  A  ...  A  rc„. 

def  def  def 

To  show  nc!  A  ...  A  rcn  <  rc\  A  ...  A  rcn,  repeatedly  use  Assumption  2.17  (A  Elim)  on 
page  34  to  get 

def  def  def 

for  all  h  in  1 ...  n  we  have  nci  A  . . .  A  rcn  <  rch. 
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Then  rcon-sub  gives 

ilef  def 

for  all  k  in  1 ...  n  we  have  rct  A  ...  A  rcn  <  rc^ 
and  repeated  use  of  and-intro-sub  gives 

def  def 

rC(  A  ...  A  rc„  <  m  A ...  A  rc„. 

The  first  and  last  displayed  formulae  imply  our  conclusions.  □ 

Just  as  we  did  with  tuples  imp,  we  can  define  a  function  that  simplifies  refinement 
types  that  is  justified  by  Lemma  2.24  (Refinement  Constructor  Intersection)  on  page  41. 

fun  rconsimp  (rc\  A  ...  A  rc„)  » 

def  def 

r«i  A  ...  A  rcn 

Soundness  of  this  follows  from  one  use  of  Lemma  2.24  (Refinement  Constructor  Intersec¬ 
tion)  on  page  41: 

Fact  2.25  (Rconsimp  Sound)  Ifr  □  tc  then  rconsimp  r  terminates  and  has  the  form  rc, 
and  rconsimp  r  =  r. 

Tuple-sub  tells  us  that  one  product  refinement  type  is  a  subtype  another  if  corresponding 
components  are  subtypes.  It  turns  out  that  the  converse  is  also  true,  although  to  prove  it  we 
must  first  strengthen  the  induction  hypothesis  as  shown  in  the  following  theorem. 

After  we  introduce  polymorphic  refinement  type  constructors,  this  will  be  a  trivial 
consequence  of  properties  of  the  i  operator  that  we  use  to  prove  that  each  refinement  type 
has  finitely  many  distinct  refinements;  until  then,  we  need  a  direct  proof. 

Lemma  2.26  (Tuple  Subtyping)  If 

rn  *  ...  *tm  A  ...  A  rln  *  ...  *  Thn  <  k\\  *  ...  *  kh\  A  ...  A  k\  m  *  •  •  •  *  ^hm 
then  for  all  j  between  l  and  h  we  have 

Tj\  A  ...  A  i *jn  <  kj\  A  ...  A  kjm. 

Proof:  By  induction  on  the  derivation  of  our  hypothesis. 

Case:  SELF-SUB  Then  n-m  and 


for  *  in  1 ...  n  and  j  in  1 . . .  h  we  have  r,i  =  %. 
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and  there  is  a  t  such  that 

1*11  *  •••  *rw  A  ...  A  Tin  *  ...  *rhn  C  t.  (2-13) 

The  only  way  to  derive  (2.13)  is  by  using  and-REF  with  the  premises 

for  i  in  1 ...  n  we  have  ru*  ...  *  C  t. 

and  this  can  only  be  derived  by  using  TUPLE-REF  when  t  has  the  form  t\  *  ...  *tn  and  the 
premises  of  TUPLE-REF  are 

for  i  in  1 . . .  n  and  j  in  1 ...  h  we  have  r#  C  tj. 

Then  AND-REF  gives 

for  j  in  1 . . .  h  we  have  A ...  A  rjn  c  tj 
and  then  SELF-SUB  gives 

for  j  in  1 ...  h  we  have  A  ...  A  rjn  <rji  A  ...  A  rjn 


which  is  our  conclusion. 


Case:  and-elim-r-sub 


Then  n>  m  and 


r  n  *  . . .  *  rM  A  ...  A  rlm*...*rhm  =  ku  *  . . .  *  kM  A  ...  A  k\m  *  ...  *  khm. 

Thus 

for  j  in  1 ...  h  and  i  in  1 ...  m  we  have  =  kji. 

Thus  and-elim-l-sub  and  and-elim-r-sub  give 


for  j  in  1 . . .  h  we  have  r,i  A  ...  A  rjn  <  kj i  A  ...  A  kjm. 


which  is  our  conclusion. 


Case:  and-elim-l-sub 


Similar. 


Case:  and-intro-sub 
intro-sub  are 


Then  there  is  an  i  in  1 ...  m  —  1  such  that  the  premises  of  and- 


m  *  •  •  •  *  rM  A  . . .  A  rln  *  . . .  *  rhn  <  ku  *  . . .  *  hi  A  . . .  A  ku  *  . . .  *  khi 
and 


rn  *  ...  *  I'm  A  ...  A  rln  *  ...  *  rhn  <  *  ...  *  fefc(i+i)  A  ...  A  k\m  *  ...  *  khm. 


44 


CHAPTER  2.  REFINEMENT  TYPE  INFERENCE 


Two  uses  of  the  induction  hypothesis  give 

for  j  in  1 ...  h  we  have  r,i  A  ...  A  rjn  <  kj\  A  ...  A  kji 


and 

for in  1 . . .  h  we  have  r,i  A  ...  A  rj„  <  A  ...  A 
Combining  these  with  and-intro-sub  gives 

for  j  in  1 . . .  /i  we  have  r,i  A  . . .  A  rj„  <  kji  A ...  A  &jm, 
which  is  our  conclusion. 

Case:  trans-sub  For  the  duration  of  this  case,  we  will  givern*. .  .*rht  A. .  .Arln*. .  .*?•*„ 
the  name  r.  There  is  a  p  such  that  the  premises  of  trans-sub  are 


r  <  p 


and 

P  <  k\\  *  . . .  *  kh\  A  . . .  A  k\m  *  ...  *  khm . 

By  Theorem  2.21  (Subtypes  Refine)  on  page  36,  there  is  a  t  such  that  both  r  and  p  refine  t. 
By  the  form  of  r  we  know  that  t  has  the  form  tx  *  *  th,  so  by  Fact  2.12  (Tuple  Refines) 

on  page  32  we  know  that  p  has  the  form  pu  * . . .  *  pm  A  . . .  A  p\q  *  . . .  *  phq. 

Two  uses  of  the  induction  hypothesis  give 

for  j  in  1 ...  h  we  have  rj j  A  ...  A  rjn  <  p,i  A  . . .  A  pjq 


for  j  in  1 ...  h  we  have  pj\  A 
Then  we  can  use  TRANS-SUB  to  get 


a  Pjq  <  kji  A  ...  A  kjm. 


for  j  in  1 . . .  h  we  have  rji  A  ...  A  rjn  <  A  . . .  A  fcjm. 


which  is  our  conclusion. 

Case:  arrow-sub 

Case:  arrow-and-elim-sub 

Case:  rcon-sub 

Case:  rcon-and-elim-sub 

None  of  these  cases  can  arise  because  they  are  not  consistent  with  the  form  of  our  hypothesis. 

Case:  TUPLE-SUB  Then  n  =  1  and  m  =  1  and  the  premises  of  TUPLE-SUB  are  our 
conclusion. 
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Case:  TUPLE-and-ELIM-sub  Then  n  =  2  and  m  =  1  and  our  hypothesis  has  the  form 

(Pi  *  •  •  •  *  Ph)  A  (p[  <  (p\  A  )  *  ...  *  (pk  A  p'h). 

Self-sub  gives 

for  j  in  1 ...  h  we  have  p,  A  p'  <  p,  A  p', 

which  is  our  conclusion.  □ 

From  this  it  trivially  follows  that  if  a  valid  subtyping  inference  looks  like  it  could  have 
been  inferred  by  using  TUPLE-SUB,  then  it  can  be  inferred  by  using  TUPLE-SUB: 

Corollary  2.27  (TUPLE-SUB  Inversion)  If 

r\*...*rh<k !*...*  Is* 

then 

for  iin\...hwe  have  <  k{. 

Proof:  Use  Lemma  2.26  (Tuple  Subtyping)  on  page  42  with  n  —  m  =  1.  □ 

The  only  use  we  ever  make  of  Lemma  2.26  (Tuple  Subtyping)  on  page  42  is  in  the 
proof  of  Corollary  2.27  (TUPLE-SUB  Inversion)  on  page  45.  It  is  tempting  to  conjecture  that 
we  could  eliminate  Tuple  Subtyping  by  using  tuplesimp  to  prove  TUPLE-SUB  Inversion 
directly.  Unfortunately,  this  does  not  work.  The  attempted  proof  of  TUPLE-SUB  Inversion 
has  the  same  shape  as  the  proof  of  Tuple  Subtyping,  except  many  cases  vanish  because* 
the  hypothesis  has  such  a  special  form.  The  TRANS-SUB  case  remains,  though,  and  that  is 
where  the  proof  goes  wrong.  To  get  the  weaker  induction  hypothesis  to  apply,  we  must 
first  use  tuplesimp  on  the  premises  of  TRANS- SUB.  But  then  we  have  no  guarantee  that  the 
induction  makes  progress,  since  using  tuplesimp  makes  the  type  derivation  larger. 

Similar  reasoning  to  Lemma  2.26  (Tuple  Subtyping)  on  page  42  gives  analogous  facts 
about  refinement  type  constructors: 

Fact  2.28  (Refinement  Constructor  Subtyping)  // 

rci  A  ...  A  rc„  <  kc\  A  ...  A  kcm 

then 

<ief  def  def  def  def 

rc\  A  ...  A  rcn  <  kc\  A  ...  A  kcm. 

Fact  2.29  (Rcon-sub  Inversion)  If 

rc  <  kc 

def 

rc  <  kc. 


then 
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After  we  introduce  polymorphic  refinement  type  constructors,  both  monomorphic  re¬ 
finement  type  constructors  and  tuples  will  be  special  cases  of  polymorphic  refinement  type 
constructors.  Then  we  will  introduce  Corollary  5.13  (Arbitrary  Constructor  Subtyping)  on 
page  250,  which  generalizes  both  Fact  2.29  (RCON-SUB  Inversion)  on  page  45  and  Corollary 
2.27  (Tuple-sub  Inversion)  on  page  45. 


2.6.2  Splitting 

Under  appropriate  assumptions  about  the  refinement  types  of  or  and  not,  we  should  expect 
the  expression 


fn  x:bool  =>  or  (x,  not  x) 

to  have  the  refinement  type  T  &*,/-♦  tf.  The  reasoning  that  leads  to  the  conclusion  that 
the  above  function  always  returns  a  value  of  type  it  relies  upon  the  assumption  that  all 
boolean  values  have  one  of  the  types  tt  or  ff.  This  section  formalizes  this  assertion  as 
Tw  -  {tt,ff}\  this  assertion  is  used  in  type  inference  in  the  SPLIT-TYPE  rule  in  Figure  2.6 
on  page  2.6. 

To  see  why  we  need  to  use  the  fact  that  x  {tt,ff},  suppose  we  made  the 

assumption  false  by  adding  a  new  constructor  maybe  with  refinement  type  runit  — ►  T iool. 
What  is  the  best  type  we  could  expect  from  not  if  it  is  passed  an  argument  with  type  T^,? 

At  the  type  level,  the  behavior  of  not  must  be  monotone.  Since  tt  <  T  ^  and  not  has 
the  type  tt  — » ff,  the  type  we  get  from  not  must  be  at  least  ff.  A  similar  argument  leads  to 
the  conclusion  that  it  must  be  at  least  tt,  so  the  type  must  be  T 

We  can  repeat  this  argument  for  or  instead  of  not  and  conclude  that  if  we  pass  something 
of  type  (Tio0j  *  Tjoo/)  to  or,  then  all  we  can  know  about  the  result  is  that  it  has  the  type 
T ioo/.  Thus  the  expression  or  (maybe  () ,  not  (maybe  ()))  has  the  best  type  T ioai,  so  as 
long  as  we  have  the  maybe  constructor,  we  cannot  give  the  expression 

fn  x:bool  =>  or  (x,  not  x) 


the  type  T -» tt. 


2.6.2.1  Definition  of  Splitting 

Therefore  our  type  system  has  to  reason  about  when  a  refinement  type  can  be  split  into  a 
union  of  other  refinement  types.  We  write  the  assertion  that  all  values  of  type  r  have  one 
of  the  types  in  the  set  s  as 

r  x  a. 
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For  example,  we  have 

Tw  x  {tt,ff} 
and 

*  T  ioot  x  {tt  *  tt ,  tt  *  ff  ,ff  *  tt,ff  *  ff}. 

We  say  the  elements  of  a  are  fragments  of  r  and  that  r  splits  up  into  a. 

The  definition  of  the  splitting  relation  x:  for  expressions  in  general  relies  upon  assump¬ 
tions  about  how  the  refinement  type  constructors  behave.  We  will  need  to  assume  that 
certain  refinement  type  constructors  have  splits  to  show  that  some  refinement  types  have 
splits.  We  write  the  assumption  that  re  splits  up  into  constructors  in  the  set  ac  as 

def 

re  x  sc. 


For  instance,  starting  with  the  assumption 


T4„,  x  {tt,ff} 

about  the  refinement  type  constructors  T tt,  and  ff,  we  can  reach  the  insipid  conclusion 

Tioo,  x  {tt,ff} 

about  the  refinement  types  T iooi,  tt,  ff.  We  can  also  reach  more  interesting  conclusions, 
such  as 

Tjoo/  *  Tjaoj  x  {T bool  *  tt,  T iooi  *  ff}. 

An  important  property  of  x  is  that  if  a  value  has  a  refinement  type  r  and  r  x  a  then  the 
value  has  some  element  of  a  as  its  type.  We  will  have  to  postpone  proof  of  this  until  after 
we  define  refinement  type  inference. 

We  define  the  x  relation  in  Figure  2.5. 

The  rcon-split  rule  is  self-explanatory;  it  simply  allows  us  to  make  use  of  our  assump¬ 
tions. 

Tuple-split  allows  us  to  split  up  a  tuple  if  we  can  split  any  of  its  components.  SML 
represents  functions  that  take  multiple  arguments  either  as  curried  functions  or  as  functions 
that  take  one  argument,  which  is  a  tuple.  Without  this  rule,  type  inference  for  the  curried 
functions  would  be  much  stronger  than  type  inference  for  the  functions  that  take  a  tuple  as 
an  argument. 

The  TRANS-SPLIT  rule  lets  us  use  the  other  rules  multiple  times  to  split  up  a  refinement 
type.  Without  this,  there  would  be  no  clear  “best”  split  of  some  refinement  types;  for 
example,  TUPLE-TYPE  gives  T 4oo/  *  T boot  x  {T booi  *  tt,  T boot  *  ff  }■  and  T 4oo/  *  T boot  x 
{tt  *  Thohff  *T tool},  and  neither  of  these  splits  is  clearly  better  than  the  other.  With 
TRANS-SPLIT,  we  can  use  TUPLE-TYPE  to  split  the  fragments  of  either  of  these  splits  to  get 


*  T^j  x  {tt  *  tt,  tt  *  ff,ff  *  tt,  ff  *  ff}, 
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rcon-split: 

def 

re  x  sc 

re  x  sc 

ki  x  s 

TUPLE-SPLIT: 

.  .  .  *  fci-t  *  ki*  ki+\  *  ...*  km  X 
{ki*...*ki.l*p*ki+i*...*km\pe  a} 

TRANS-SPLIT: 

rX3|U  {k}  k  x  32 

r  X  J!  U  32 

'  equiv-splTt-l: 

r  =  k  k  x  s 

r  x  s 

EQUIV-SPLIT-R: 

p  =  k  r  x  s  U  {k} 

r  x  s  U  {p} 

elim-split: 

r  x  s  U  {k,p}  k  <  p 

rxjU  {p} 

SELF-SPLIT: 

r  x  {r} 

Figure  2.5:  Definition  of  Splitting 

which  is  in  some  sense  a  better  split  than  either  of  the  two  splits  given  earlier.  See 
Subsubsection  2.6.2.2  for  a  discussion  of  principal  splits. 

EQUIV-split-l  and  EQUIV-SPLIT-R  ensure  that  the  splitting  relation  is  invariant  under 
equivalence.  For  example,  Lemma  2.43  (Split  Intersection)  on  page  54  allows  us  to  start 
with  the  premise 

T iool  x  {tt,ff} 

and  use  that  to  conclude 

Aff  x  {tt  A  ff,ff  Aff}. 

Without  EQurv-SPLrr-L,  the  best  we  would  be  able  to  conclude  is  that  for  some  type  r 
equivalent  to  T  A  ff  we  have 

r  x  {tt  Aff,ff  Aff}. 

If  we  had  equiv-split-l  but  not  equiv-split-r,  the  best  we  could  conclude  is  that  for  some 
n  equivalent  to  tt  A  ff  and  some  r2  eq  /alent  to  ff  A  ff. 


Th,0  ff  x  {ri,rj}. 
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ELlM-SPLrr  allows  us  to  eliminate  unimportant  elements  from  splits.  For  example,  given 
Tw  x  J_iooj},  we  can  use  elim-split  and  tt  to  infer  T ^  x  {tt,ff}.  If 

we  read  the  assertion  T iao,  x  {tt,ff,  liaoi}  as  “All  values  with  type  T ioot  have  one  of  the 
types  tt,  ff,  or  ±*00/,”  it  becomes  intuitively  clear  that  -Lj can  be  eliminated  from  the 
split  without  losing  any  information. 

If  we  did  not  have  ELIM-SPLIT,  then  principal  splits  would  not  be  unique  because  the 
unimportant  elements  could  differ.  We  could  still  generate  a  unique  minimal  set  that 
contained  all  the  information  from  all  of  the  splits,  but  without  elim-split,  that  set  would 
not  be  a  split.  Since  this  set  would  be  usable  as  a  split,  the  distinction  between  it  and  the  true 
splits  would  be  formal  but  not  practical.  It  seems  better  to  erase  the  unimportant  distinction 
by  keeping  the  elim-split  rule. 

Self-split  ensures  that  each  refinement  type  has  at  least  one  split.  This  simplifies  some 
of  the  reasoning  to  come;  in  particular,  Assumption  2.50  (Split  Constructor  Consistent)  on 
page  66  is  flexible  enough  only  because  we  have  SELF-SPLIT. 

Now  we  can  prove  several  lemmas  about  how  x  interacts  with  <  and  (Z.  First  we  will 
assume  that  the  fragments  of  a  refinement  type  constructor  are  smaller  than  the  refinement 
type  constructor  itself: 


Assumption  2.30  (Split  Subtype  Consistent)  //rex  s  and  kc  6  s  then  kc  <  rc. 


A  straightforward  induction  lets  us  lift  Split  Subtype  Consistent  from  a  statement  about 
“x”  and  “ < ”  to  a  statement  about  “x”  and 


Theorem  2.31  (Splits  Are  Subtypes  I)  Ifr  x  s  U  {k}  and  r  C  t  then  k  <r. 
Proof:  By  induction  on  the  derivation  of  r  x  s  U  {fc}. 


Case:  rcon-split 

RCON-SPLIT  is 


Then  r  has  the  form  rc  and  k  has  the  form  kc  and  the  premise  of 

def  , .  . 

rc  x  sc  U  {  kc  } . 


def 

By  Assumption  2.30  (Split  Subtype  Consistent)  on  page  49,  this  implies  that  kc  <  rc. 
Using  RCON-SUB  on  this  gives  kc  <  rc,  which  is  our  conclusion. 


Case:  tuple-split 


Then  r  has  the  from  k\  * ...  *  fcj_i  *ki*  ki+\  * . . .  *  km  and  k  has  the 


form  fc]  *  ...  *  fcj_i  *p*  1  * ...  *  km,  and  the  premise  of  tuple-split  is 


iiXi'll  {p}. 

The  only  way  we  could  have  inferred  r  C  t  is  by  using  tuple-ref  where  t  has  the  form 
t\*  ...*tm  and  one  of  the  premises  of  TUPLE-REF  is 

for  j  in  1 . . .  m  we  have  kj  □  tj. 
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This  is  true  for  j  =  t  as  well,  so  we  can  use  the  induction  hypothesis  to  give 

p<ki. 

By  SELF-SUB, 

for  j  in  1 ...  m  we  have  kj  <  kj , 

and  TUPLE-SUB  gives 

k\  *  .  .  .  *  fcj_l  *p*  ki+i  *  ...  *  km  <  k\  *  k{-\  *  ki*  k{+ 1  *  ...  *  km , 

which  is  our  conclusion. 

Case:  trans-split  Then  a  U  {&}  =  ai  U  a2  where  the  premises  of  trans-split  are 

r  x  U  {p} 


If  k  £  *i,  then  our  induction  hypothesis  gives  k  <  r,  and  we  are  done. 

If  k  £  32,  then  we  reach  our  conclusion  less  directly.  Our  induction  hypothesis  gives 
p  <  r,  and  Theorem  2.21  (Subtypes  Refine)  on  page  36  gives  a  t  such  that  pC(.  Then 
we  can  use  our  induction  hypothesis  again  to  get  k  <  p,  and  then  trans-sub  gives  k  <  r, 
which  is  our  conclusion. 

Case:  EQUIV-split-L  Then  the  premises  of  EQUIV-SPLIT-L  are  r  =  p  and  pxj.  Theorem 

2.21  (Subtypes  Refine)  on  page  36  gives  p\Zt,  and  our  induction  hypothesis  gives  k  <  p. 
TRANS-SUB  then  gives  k  <  r,  which  is  our  conclusion. 

Case:  EQUIV-split-r  Then  we  must  have  a  U  W  =  s'  U  {p}  where  the  premises  of 

EQUIV-SPLIT-R  arepsp'andrxa'U  {p'}. 

If  k  £  a',  then  k  £  s'  U  {p'},  so  we  can  use  our  induction  hypothesis  immediately  to  get 
k  <  r. 

If  k  =  p,  then  our  induction  hypothesis  only  gives  p'  <  r.  Since  p  =  p',  trans-sub 
gives  p  <  r,  which  is  our  conclusion. 

Case:  ELIM-SPLIT  Then  a  U  {k}  =  a'  U  {p}  and  the  premises  of  ELIM-SPLIT  are  r  x 

a'  U  {p',p}  and  p'  <  p.  Since  k  must  be  in  a'  U  {p',p},  our  induction  hypothesis  gives 
k  <r. 

Case:  self-split  Then  k  =  r,  and  self-sub  gives  our  conclusion.  □ 

It  is  a  trivial  consequence  of  this  show  that  x  and  C  interact  reasonably: 
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Corollary  2  32  (Split  Types  Refine  I)  Ifr  x  s  and  k  €  s  and  r  Cl  then  k  [it. 

Proof:  Let  k  in  s  be  given.  By  Theorem  2.31  (Splits  Are  Subtypes  I)  on  page  49,  k  <  r. 
By  Theorem  2.21  (Subtypes  Refine)  on  page  36,  k  at.  □ 

The  following  fact  similar  to  Theorem  2.31  (Splits  Are  Subtypes  I)  on  page  49  is 
provable,  but  the  proof  is  too  similar  to  the  proof  of  Theorem  2.31  (Splits  Are  Subtypes  I) 
on  page  49  for  it  to  be  worthwhile  to  include  it  here. 

Fact  233  (Splits  Are  Subtypes  II)  Ifr  x  a  u  {fc}  and  k  a  t  then  k  <  r. 

We  have  an  immediate  corollary  to  Fact  2.33  (Splits  Are  Subtypes  II)  on  page  5 1  that  is 
completely  analogous  to  Corollary  2.32  (Split  Types  Refine  I)  on  page  51: 

Fact  234  (Split  Types  Refine  II)  Ifr  x  s  and  k  6  s  and  kat  then  r  at. 

Refinements  of  an  ML  type  of  the  form  t\  — >  <2  all  have  a  simple  form.  If  r  a  tx  — ►  t2, 
we  can  use  self-split  to  infer  r  x  {r},  and  we  can  use  equiv-split-R  to  replace  the 
element  of  that  split  by  arbitrarily  many  equivalent  elements.  A  simple  induction  on  the 
derivation  ofrxa  for  any  s  tells  us  nothing  more  interesting  than  this  can  happen.  This  is 
important  in  the  SPLIT-TYPE  case  of  Lemma  2.70  (Value  Substitution)  on  page  93. 

Fact  235  (Splits  of  Arrows  are  Simple)  Ifr  a  tx  —>t2  and  r  x  3  and  k  e  s  then  r  =  fc. 

It  is  possible  to  imagine  a  refinement  type  having  an  empty  split.  This  would  be 
consistent  with  the  intuitive  meaning  of  splitting  if  there  were  no  way  to  construct  a  value 
having  that  type;  for  instance,  we  might  expect  ±i„0i  to  split  into  the  empty  set.  However, 
allowing  empty  splits  causes  type  inference  to  behave  strangely;  see  the  discussion  of  the 
SPLIT-TYPE  rule  on  page  62.  We  will  outlaw  refinement  types  with  empty  splits;  thus 
possible  splits  of  ±400<  are  {-Lj00<}  and  trivial  variants  of  this  such  as  {J-6oo<  A  -Lj00j}.  First 
we  outlaw  empty  splits  for  refinement  type  constructors: 

Assumption  236  (Refinement  Constructor  Splits  are  Nonempty)  If  rc  x  sc  then  sc  is 
nonempty. 

From  this  it  is  easy  to  show  that  no  refinement  type  can  have  an  empty  split: 

Fact  237  (Splits  are  Nonempty)  Ifr  x  s  then  s  is  nonempty. 


This  could  be  proved  by  induction  on  the  derivation  of  r  x  s. 
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2.6.22  Principal  Splits 

The  definition  of  the  x  relation  gives  infinitely  many  splits  of  each  refinement  type.  For 
example,  tt  has  the  splits  {**},  {tt  A  tt},  {tt,tt  A  tt},  and  infinitely  many  others.  A 
practical  type  inference  algorithm  will  only  have  time  to  consider  a  finite  number  of  these. 
In  this  Subsubsection  we  will  add  an  assumption  that  makes  it  possible  for  type  inference 
to  consider  only  one  split.  This  split  will  be  a  principal  split  in  the  sense  we  will  define 
below.  If  we  identify  two  splits  when  there  is  a  one-to-one  correspondence  between  them 
where  equivalent  elements  correspond,  then  any  well-formed  refinement  type  has  exactly 
one  principal  split. 

First,  we  shall  make  a  distinction  between  splits  with  fragments  that  could  be  eliminated 
by  using  eum-SPLIT  and  splits  without  such  fragments.  The  unnecessary  fragments  add 
complexity. 

Definition  2.38  (Irredundant  Splits)  We  say  a  split  3  is  redundant  if  any  two  elements  of 
s  are  comparable.  Otherwise  we  say  it  is  irredundant. 

A  given  refinement  type  will  have  many  splits,  and  some  of  them  are  more  informative 
than  others.  A  split  is  informative  because  it  introduces  smaller  refinement  types  into  the 
environment.  Thus  one  irredundant  split  is  more  informative  than  another  if  the  former  has 
types  smaller  than  the  types  in  the  latter;  to  put  it  formally, 

Definition  2.39  (Informative  Splits)  Given  two  splits  s\  and  s2  ofr,  we  say  thats\  is  more 
informative  than  s2  if  each  element  of  s\  is  less  than  some  element  of  s2. 

Our  goal  is  to  have  unique  most  informative  irredundant  splits: 

Definition  2.40  (Principal  Splits)  We  say  that  3  is  a  principal  split  ofr  if  3  is  an  irredundant 
split  ofr  that  is  more  informative  than  any  other  irredundant  split  ofr. 

Once  we  have  one  principal  split,  we  need  not  worry  about  looking  for  another  because 
there  are  no  other  principal  splits  that  are  different  in  any  interesting  way. 

Theorem  2.41  (Unique  Principal  Splits)  Given  any  two  principal  splits  of  a  well-formed 
refinement  type ,  there  is  a  one-to-one  correspondence  between  them  in  which  the  corre¬ 
sponding  refinement  types  are  equivalent. 

Proof:  Suppose  s  and  s'  are  principal  splits  of  r,  and  p  is  in  s.  By  symmetry,  it  is  sufficient 
to  find  a  p'  in  s'  such  that  p  =  p'. 

Since  s  is  more  informative  than  s',  there  is  a  p'  in  s'  such  that  p  <  p' .  Since  s'  is  more 
informative  than  s,  there  is  a  p"  in  s  such  that  p'  <  p".  By  TRANS-SUB,  these  imply  p  <  p". 
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Since  s  is  irredundant,  we  must  have  p  =  p".  Using  this  to  rewrite  p'  <  p"  gives  p'  <  p. 
This  and  p  <p'  imply  p  =  p',  which  implies  our  conclusion.  □ 


Generally  speaking,  refinement  types  that  are  not  well- formed  may  not  have  principal 
splits.  For  example,  suppose 


Tioo /  X  {«,#} 


and 


Tjoo/  X  {  tty  ff  ■)  -Liooi}. 


In  this  case  the  malformed  type  ( tt  A  runit)  *  T would  have  the  splits 


{( tt  A  runit)  *  tt,(tt  A  runit)  *  ff} 


and 

{(tt  A  runit)  *  tt,(tt  A  runit)  *  ff,(tt  A  runif)*  -Ljoo/}, 

among  others.  These  splits  are  both  irredundant  because  ill-formed  refinement  types  are 
incomparable,  and  for  the  same  reason  neither  split  is  more  informative  than  the  other. 
By  similar  reasoning,  no  splits  of  (tt  A  runit)  *  T ^  will  be  redundant  or  more  or  less 
informative  than  any  other  splits.  Thus  we  only  will  be  interested  in  principal  types  for 
well-formed  refinement  types. 

If  we  want  to  have  unique  most  informative  splits,  we  need  to  have  a  split  more 
informative  than  any  two  given  splits.  Thus,  if  we  have  splits  jq  and  a2  of  a  well-formed 
refinement  type  r  then  we  need  to  be  able  to  find  an  33  such  that 

r  x  a3 


and 


for  all  k2  6  33  there  is  a  k\  €  sj  such  that  k2  <  k\ 


and 


for  all  kj  €  a3  there  is  a  &2  G  a2  such  that  h  <ki. 


This  will  be  true  if  splitting  interacts  in  a  natural  way  with  intersection:  whenever  p  x  3 
and  p  and  p'  refine  the  same  ML  type,  we  need  to  ensure  that  pAp'  x  {p"  A  p'  |  p"  <E  s}. 
This  is  intuitively  plausible  because  if  a  value  is  in  p  A  p'  is  in  both  p  and  p'.  Since  it  is  in  p 
it  must  be  in  some  p"  €  s,  and  since  it  is  in  both  p"  and  p'  it  must  be  in  p"  A  p'. 

This  property  allows  us  to  construct  an  33  more  informative  than  both  and  s2.  Let 

33  =  {kj  A  &2  |  G  3i  and  hi  €  32}. 

The  property  mentioned  in  the  previous  paragraph  guarantees  that 

for  all  k\  in  s\  we  have  k\  x  {k\  A  k2  \  hi  s  32} 

and  then  we  can  repeatedly  use  trans -split  to  get 


r  x  {k\  A  hi  |  &i  e  3i  and  hi  €  32}, 


54 


CHAPTER  2.  REFINEMENT  TYPE  INFERENCE 


which  means  that  s3  has  the  properties  we  want. 

What  is  the  best  way  to  ensure  that  splitting  and  intersection  interact  this  way?  It  is 
sufficient  to  assume  that  predefined  splitting  and  predefined  intersection  interact  this  way 
for  refinement  type  constructors: 

def  def 

Assumption  2.42  (Predefined  Split  intersection)  If  rc  C  tc  andkc  C  tcand 

def 

rc  x  sc 

then 

rc  A  kc  x  {rc'  A  kc  |  rc'  £  sc}. 

Now  we  are  in  a  position  to  prove  that  the  analogous  property  holds  for  refinement  types 
in  general: 

Lemma  2.43  (Split  Intersection)  Ifr  O  t  and  k  c  t  and 

T  X  S 

then 

r  A  k  x  {r'  A  k  \  t  G  3}. 


Proof:  By  induction  on  the  derivation  ofrxs. 

Case:  RCON-SPLIT  Then  r  has  the  form  rc  and  t  has  the  form  tc  and  s  has  the  form  sc 
and  the  premise  of  rcon-split  is 

def 

rc  x  sc. 

def  def 

Since  k  (Z  tc,  we  know  that  k  has  the  form  kc\  A  ...  A  kcn.  Let  kc  =  kc \  A  ...  A  kcn.  By 
Lemma  2.24  (Refinement  Constructor  Intersection)  on  page  41, 

def 

rc  A  k  =  tc  A  kc. 

By  Assumption  2.42  (Predefined  Split  Intersection)  on  page  54, 

def  def  r  .  def  , 

rc  A  sc  x  (rc  A  kc  |  rc  €  sc}. 

Rcon-split  and  equiv-split-l  give 

rc  A  k  x  {rc'  A  kc  |  rc'  £  sc}. 

By  Lemma  2.24  (Refinement  Constructor  Intersection)  on  page  41  we  know  that  for  rc' t  sc 
1  def 

we  have  rc'  A  k  =  rc  A  kc.  Thus  repeated  use  of  equiv-split-R  gives 

rc  A  k  x  {rc'  A  k  |  rc1  6  sc} 
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which  is  our  conclusion. 

Case:  TUPLE-SPLIT  Then  r  has  the  form  rj  * . . .  *  rn  and  there  is  an  i  such  that  the  premise 
of  TUPLE-SPLIT  is  i\  s'  where 

3  =  {n  *  ...  *  r;_i  *  r"  *  ri+\  *  . . . *  rn  |  r"  £  a'}. 

Since  rdf,  we  know  that  t  has  the  form  1 t  Since  A  d  f,  we  know  that  k  has  a 

form  that  allows  us  to  repeatedly  use  Lemma  2.22  (Tuple  Intersection)  on  page  40  to  find 
through  K  such  that 

k  =  kx  *  ...  *  kn. 

By  induction  hypothesis, 

r;  A  fci  x  {r"  A  A;  |  r"  £  s'} 

and  tuple-split  gives 
(ri  Aii)*,..*  (r„  A  kn)  >: 

{(n  A  A^  *  ...  *  (r\_,  A  ki-i)  *  (r"  A  A<)  *  (ri+,  A  Ai+,)  *  . . .  *  (rn  A  An)  |  r"  £  s'}. 

All  that  remains  to  do  is  to  simplify  this  until  it  looks  like  our  conclusion.  Lemma  2.22 
(Tuple  Intersection)  on  page  40  gives 

(rj  *  ...  *  rn)  A  (A)  *  ...  *  k„ )  =  (rj  A  k} )  *  . . .  *  (r„  A  kn) 

and  trivial  reasoning  about  A  then  gives 

r  A  k  =  (r\  A  k\)  *  ...  *  (rn  A  kn). 

Equiv-split-l  gives 

r  Ak  x  {(ri  A  Ai)*...*(r<_!  A  ki-{)  *  (r”  A  ki)  *  (ri+\  A  Aj+i)  *  . . .  * (rn  A  kn)  |  r"  £  s'}. 

Lemma  2.22  (Tuple  Intersection)  on  page  40  gives  for  r"  in  s'  we  have 

(f*l  *  . . .  *  rj_]  *  r"  *  ri+l  *  ...  *  rn)  A  (k\  *  ...  *  kn)  = 

A  k\)*  ...  *  (ri_!  A  )  *  (r"  A  ki )  *  (ri+)  A  Ai+1)  *...*(r„A  kn) 

Trivial  reasoning  about  A  gives 

(rt  *  ...  *  *  t"  *  T\+1  *  ...  *  Tn)  A  (k\  *  ...  *  kn)  = 

(r,  *  ...  *  rj_i  *  r"  *  ri+i  *...*rn)Ak 

so  for  r"  in  s'  we  have 

(rl  *  ■  •  •  *  ^i-i  *  r"  *  ri+1  *  ...*rn)  Ak  = 

(r,  A  kt)  * ...  *  (r<_,  A  A,-_i )  *  (r"  A  A,)  *  (ri+,  A  A,+)  )*...*  (r„  A  k„). 
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Repeated  use  of  EQUiv-SPLIT-R  gives 

r  A  k  x  {(rt  *  ...  *  r^_i  *  r"  *  ri+l  *  . . .  *  rn)  A  k  )  r"  6  a'} 
and  by  simple  manipulation  and  the  definition  of  a  this  implies 

rAfcx{r'Afcjr'es}t 


which  is  our  conclusion. 

Then  a  has  the  form  a\  U  j2  where  the  premises  of  trans-split  are 


Case:  trans-split 


r  ^  5i  U  {p} 


and 

By  induction  hypothesis. 


P  ^  s2- 


r  A  k  x  {r1  A  k  |  r'  €  Si  U  {?}} 
and  by  set  theory  this  is  equivalent  to 

r  A  k  x  {r'  A  k  |  r'  £  st }  U  {p  A  k}. 

By  Corollary  2.32  (Split  Types  Refine  I)  on  page  51,  p  C  t.  By  induction  hypothesis, 

p  A  k  >:  {r'  A  k  j  r'  G  32}- 


Then  trans-split  gives 

r  A  k  x  {/  A  k  \  t'  G  Si  U  32}? 


which  is  our  conclusion. 


Case:  equiv-split-l 


Then  the  premises  of  equiv-split-l  are 


T  =  p 


By  Theorem  2.21  (Subtypes  Refine)  on  page  36,  pdf,  so  we  can  use  the  induction 
hypothesis  to  get 

p  A  k  x  {/  A  k  |  t  €  3}. 

Trivial  reasoning  about  A  gives  r  A  k  =  p  A  k,  so  we  can  use  EQUIV-SPLIT-L  to  get 


r  A  k  x  {/  A  k  |  r'  G  3}, 
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which  is  our  conclusion. 


Case:  equiv-split-r 


Then  3  has  the  form  s' Up  where  the  premises  of  equiv-split-r  are 


P  =  P 


r  x  s'  U  p' . 


and 

By  induction  hypothesis, 

r  A  k  x  {r1  A  k  |  r'  £  a*}  U  {p'  A  fc}. 

Trivial  reasoning  about  A  gives  p'  A  k  =  p  A  k,  so  we  can  use  EQUIV-SPLIT-R  to  get 

r  A  fc  x  {r'  A  k  |  r'  £  a'}  U  {p  A  fc}, 

which  is  our  conclusion. 

Then  s  has  the  form  s'  U  {p}  where  the  premises  of  ELIM-SPLIT  are 


Case:  elim-split 


r  x  s’  U  {p\p} 


and 

P  <P- 

By  induction  hypothesis, 

r  A  k  X  {r1  A  fc  |  r'  €  U  {p  A  k,p'  A  k}. 
Trivial  reasoning  about  A  gives  p'  A  k  <  p  A  k,  so  elim-split  gives 

r  A  fc  X  {r'  A  fe  I  r'  e  /}  u  {p  A  k }, 


which  is  our  conclusion. 

Then  s  =  {r},  so  our  conclusion  is  r  A  fc  x  {r  A  fc},  which  follows 

□ 

Just  as  some  splits  are  more  informative  than  others,  some  splits  have  no  information 
at  all.  For  example,  the  split  tt  x  {tt,  ±iO0i}  is  useless  because  the  meaning  of  it  is  a 
truism:  all  values  of  type  tt  have  one  of  the  types  tt  or  In  general,  if  a  fragment  in  a 
split  is  equivalent  to  the  type  we  started  with,  that  split  is  useless.  Formally,  we  have  this 
definition: 

Definition  2.44  Ifr  x  s  and  there  is  ak  £  s  such  that  r  =  k,  then  we  say  that  s  is  a  useless 
split  ofr.  Otherwise  we  say  it  is  useful. 


Case:  self-split 
from  self-split. 
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A  simple  argument  tells  us  that  elements  of  a  principal  split  cannot  themselves  have 
useful  splits. 

Lemma  2.45  (Principal  Split  Implies  Useless  Splitting  Fragments) 

Fragments  of  a  principal  split  only  have  useless  splits. 

Proof:  Suppose  that  an  irredundant  split  of  a  well-formed  refinement  type  r  is  s  U  {k}, 
where  k  has  a  useful  split  s'.  Then  by  TRANS-SPLIT,  r  s  Us'.  By  definitions  of 
“informative”  and  “useful”,  a  U  s'  is  more  informative  than  a  U  {k}.  By  Theorem  2.31 
(Splits  Are  Subtypes  I)  on  page  49,  a  U  a'  is  irredundant.  Thus  a  U  {k}  is  not  a  principal 
split  of  r.  a 

We  also  have  the  converse: 

Lemma  2.46  (Fragments  of  Principal  Split  have  Useless  Splits)  An  irredundant  split  of 
a  well-formed  refinement  type  is  principal  if  all  of  its  fragments  only  have  useless  splits. 

Proof:  Suppose  3  is  an  irredundant  split  of  a  well-formed  refinement  type  r,  and  r  x  a' 
and  p  is  in  a.  We  need  to  show  that  there  is  a  p'  in  a1  such  that  p  <  p'. 

By  assumption,  there  is  a  t  such  that  r  C  t.  By  Theorem  2.31  (Splits  Are  Subtypes  I)  on 
page  49,  this  implies  p  <  r,  which  means  that  p  =  r  A  p.  Lemma  2.43  (Split  Intersection) 
on  page  54  gives 

rApx{r'Ap|r'G  a '}, 

and  then  equiv-split-l  gives 


px{r'Ap|r'e  s'}. 

By  assumption,  this  split  of  p  is  useless.  Thus  there  is  a  p'  in  s'  such  that  p  =  p'  A  p,  which 
implies  p  <  p\  which  is  our  conclusion.  □ 

We  will  use  these  two  lemmas  to  build  an  algorithm  for  finding  principal  splits  in 
Subsection  2.10.2. 


2.6.3  Refinement  Type  Inference 

Given  the  subtype  relation  described  above,  we  can  define  refinement  type  inference.  The 
notation  is  entirely  analogous  to  the  ML  case.  We  write 

VR  h  e  :  r 

to  mean  that  if  we  assume  each  free  variable  x  in  e  has  the  refinement  type  VR(ar),  then  e 
has  the  refinement  type  r. 
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If  an  expression  has  a  refinement  type,  then  it  has  an  ML  type,  and  the  refinement  type 
refines  the  ML  type;  this  is  an  informal  statement  of  Theorem  2.54  (Inferred  Types  Refine) 
on  page  68.  Since  each  expression  with  an  ML  type  has  only  one  ML  type,  all  refinement 
types  for  an  expression  refine  the  same  ML  type.  If  this  is  not  true  in  general,  then  not  all 
terms  would  have  principal  refinement  types.  For  example,  if  e  has  the  refinement  types  tt 
and  runit,  then  e  has  no  principal  type  because  tt,  runit,  and  the  malformed  type  tt  A  runit 
are  all  incomparable. 

Inferring  refinement  types  for  expressions  requires  making  assumptions  about  the  re¬ 
finement  types  of  constructors.  We  write  the  assumption  that  the  constructor  c  maps  values 
of  refinement  type  r  to  values  of  refinement  type  rc  as 

d£f 

c  :  r  t— »  rc. 

ticf 

For  example,  true  :  runit  c— >  tt.  We  will  describe  in  detail  the  properties  we  assume  for 

def 

the  :  relation  in  Subsection  2.6.4  on  page  64. 

The  rules  for  refinement  type  inference  are  in  Figure  2.6.  They  are  similar  to  the  rules 
for  ML;  we  have  made  only  the  following  changes: 

We  added  the  and-intro-TYPE  rule  for  introducing  intersections.  This  allows  us  to 
infer  one  type  for  a  function  that  describes  its  behavior  for  several  different  inputs.  For 
example,  since  •  F  fn  xzbool  =>  x  :  tt  — >  tt  and  •  F  fn  x:  bool  =>  x  :  ff  — >  ff,  we  have 
•  F  fn  x:  bool  ->  x  :  tt  — ►  tt  A  ff  — ►  ff.  We  do  not  need  a  corresponding  and-ELIM-type 
rule  because  we  can  use  WEAKEN-TYPE  and  either  and-elim-l-SUB  or  and-elim-r-sub  to 
eliminate  components  from  an  intersection  type. 

The  AND-INTRO-TYPE  rule  does  not  need  to  assume  that  r  and  k  refine  the  same  ML 
type  because  Theorem  2.54  (Inferred  Types  Refine)  on  page  68  guarantees  this. 

We  have  added  the  weaken-TYPE  rule.  This  rule  ensures  that  if  an  expression  has  a 
type,  then  it  also  has  any  larger  type.  For  example,  since  •  F  fn  x:  bool  =>  x  :  tt  —*  tt, 
and  tt  — >  tt  <  tt  — >  T iooi,  we  can  infer  •  F  f n  x :  bool  =>  x  :  tt  — >  T kooi. 

One  would  hope  that  if  the  environment  VR  has  appropriate  types  for  not  and  or.  we 
would  be  able  to  infer 

VR  F  fn  xxbool  =>  or  (not  x,  x)  :  Tj0<,/  — » tt, 

since  this  function  looks  simple  and  it  does  indeed  return  true  ()  for  any  input.  The 
SPLIT-TYPE  rule  allows  this.  We  can  derive 

VR[x  :=  tt j  F  or  (not  x,  x)  :  tt 
and 

VRjx  :=  j(f]  F  or  (not  x,  x) :  tt 
and  then  combine  these  with  split-type  and  T  4 00i  x  {tt,ff}  to  get 

VR(x  :=  T boei]  F  or  (not  x,  x)  :  tt 
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AND-INTRO-TYPE: 


weaken-type: 


SPLIT-TYPE: 


VAR-TYPE: 


abs-type: 


APPL-TYPE: 


constr-type: 


CASE-TYPE: 


TUPLE-TYPE: 


ELT-TYPE: 


FIX-TYPE: 


VR  h  e  :  r 
VRhe:fc 
VRhe:rAJt 

VR  h  e:r  r  <  k 
VRhe:i 

As  x  a 

for  all  p  in  a  we  have  VR[s  :=  p\\~  e:  r 
VR[®  :=  A]  F  e  :  r 

VR(as)  =  r  rCt 
VR  h  x  :r 

VR[g  :=  r]  i~  e  :  k  r  Q  t 
VR  (~  fn  x:t  =>  e  :  r —*  k 

VR  h  e\  :  k  — ►  r  VR  h  e2  :  k 

VR  I—  ti'.T 

c  d?f  r  «-»  rc  VR  h  e  :  r 
VR  he  e:« 

VR  F  e0  :  rc 
r  C.  u 

for  all  i  in  1 . . .  n  and  all  k,  if  Ci  k  *->  rc  then  VR  F  e* :  k  — » r 
rtom(VR)  h- (case  eg  of  C|  =>  ei  I  ...  I  Cn  =>  en  end:u)  ::  u 
VR  F  (case  eo  of  ci  =>  ej  I  ...  I  c„  =>  en  end:u):r 

for  i  in  1 ...  n  we  have  VR  h  ej :  r( 

VR  F  (ei ,  ...,  en)  :  rt  *  ...  *  rn 

VR  I -  e:r\*  ...  *rn 
VR  F  elt _m_n  e  :  rm 

r  (Z  — ♦  £2 

VR[/  :=  rj  F  (fn  x:t\  =>  e)  :  r 
VR  F  (f  ix  =>  fn  x:t\  ->  e)  :  r 

Figure  2.6:  Monomorphic  Refinement  Typing  Rules 
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and  then  use  abs-type  to  get 

VR  H  fn  x :  bool  =>  or  (not  x,  x)  :  T 
which  is  what  we  want. 

We  could  get  the  same  result  by  deleting  the  split-type  rule  and  adding  the  rule 

r  x  {ri,...  ,rn}  r ->  &  [Z  t 

SPLIT-SUB: - - t  - - . T 

ri— >«A...Ar„— »«<r— 

to  the  subtyping  relation.  In  this  case,  we  would  again  start  by  deriving 

VR[x  :=  tt\  h  or  (not  x,  x)  :  tt 
and 

VR[x  :=  ff]  H  or  (not  x,  x)  :  tt. 

Then  we  would  apply  abs-TYPE  to  each  of  these  to  get 

VR  h  fn  x:bool  =>  or  (not  x,  x)  :  tt—*  tt 


and 

VR  h  fn  x:bool  =>  or  (not  x,  x)  :  ff  — ►  tt. 

Combining  these  with  and-INTRO-TYPE  gives 

VR  h  fn  x'.bool  =>  or  (not  x,  x)  :  ff  — » tt  A  tt  — » tt, 

and  then  WEAKEN-TYPE  and  ff  —>  tt  A  tt  —*  tt  <  T iool  ->  tt  (from  SPLIT-SUB)  give 

VR  1- f n  x’.bool  =>  or  (not  x,  x) :  Ti(>0<  — > 


which  is  our  conclusion. 

If  have  SPLIT-TYPE  but  not  SPLIT-SL  the  types  ff  — *  tt  A  tt  — ►  tt  and  T  \>00i  —>  tt  are 

not  equivalent,  even  though  all  values  wan  one  type  also  have  the  other  type.  If  instead  we 
have  split-sub  but  not  split-type,  this  anomaly  does  not  happen.  In  this  sense,  split-sub 
is  cleaner  than  split-type.  It  is  an  open  question  whether  adding  split-sub  would  cause 
inequivalent  types  to  always  have  different  inhabitants. 

However,  after  we  add  let  statements  in  Chapter  4,  split- type  becomes  stronger  than 
split-sub.  For  example,  if  we  assume  the  best  type  for  the  expression  y  mod  3  =  0  is 
T tool,  we  would  still  like  the  statement 


let  x  =  (y  mod  3=0) 
in 

or  (not  x,  x) 
end 
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to  have  the  refinement  type  tt.  Split-type  can  do  this,  but  Split-sub  cannot  because  there 
is  no  subexpression  of  the  l*t  statement  with  an  appropriate  arrow  type. 

We  could  still  have  a  strong  system  with  SPLIT-SUB  if  we  defined  let  statements  as 
macros;  for  example,  the  above  let  statement  would  be  an  abbreviation  for 

(fn  x:  bool  => 
or  (not  x,  x)) 

(y  mod  3=0). 

Taking  this  approach  when  the  let  statement  introduces  polymorphism  requires  first-class 
polymorphism,  which  is  beyond  the  scope  of  this  thesis. 

At  this  point  we  need  to  combine  all  the  above  considerations  into  a  decision.  We  will 
keep  split-type  because  we  want  the  proofs  in  this  chapter  to  be  a  special  case  of  the 
proofs  in  Chapter  4.  We  will  omit  SPLIT-SUB  for  brevity,  since  there  is  no  harm  in  having 
inequivalent  types  with  identical  inhabitants. 

TheSPLiT-TYPE  rule  leads  to  at  least  two  problems  if  we  allow  empty  splits.  The  first 
problem  is  that  empty  splits  can  be  used  to  infer  a  malformed  refinement  type  for  an 
expression.  For  example,  if  we  suppose  that  {},  then  we  can  use  SPLIT-TYPE  to  infer 

[a;  :=J_4oo(]  h  ()  ;  tt  A  (tt  — ►  tt). 

This  problem  can  be  fixed  by  adding  a  premise  r  C  t  to  the  SPLIT-TYPE  rule.  The  revised 
rule  would  read 

k  X  3 

for  all  p  in  s  we  have  VR(®  :=  p]  I-  e  :  r 
r  C  t 

rtom(VR)  h  e  ::  t 
VR[®  :=  fe]  h  e  :  r. 

By  explicitly  requiring  the  resulting  refinement  type  to  refine  the  ML  type  for  the  expression, 
we  outlaw  malformed  types. 

Another  problem  with  empty  splits  is  more  difficult  to  solve.  Empty  splits  cause 
variables  in  the  environment  that  appear  nowhere  in  an  expression  to  affect  the  type  of  the 
expression.  For  example,  still  assuming  that  -L4ooix  {},  we  can  use  split- type  to  prove 

[*  :=-U <wt]  F  true  ()  :  ff. 

This  conclusion  is  reasonable  in  an  eager  language  because  there  are  no  values  of  type 
-Li,,,/.  However,  it  is  strange  because  if  we  changed  the  environment  to  [x  :=  ff j,  we  would 
no  longer  be  able  to  prove  true  ()  :  ff.  Since  we  assume  in  many  places  that  changing 
types  in  the  environment  for  unused  variables  does  not  affect  the  refinement  type  of  an 
expression,  this  would  invalidate  many  of  the  proofs  below.  To  make  it  clear  where  we 
assume  this,  we  will  state  it  as  a  fact  now,  and  make  explicit  reference  to  this  fact  when  we 
assume  it  is  true. 
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Fact  2.47  (Non-free  Variables  are  Ignored)  Ifx  is  not  free  in  e,  then  VR(x  :=  rj  (-  e  :  k 
if  and  only  ifV  R  h  e  :  k. 

Proof  of  this  is  by  two  trivial  inductions,  one  on  the  derivation  of  VR[x  :=  r)  H  e  :  k  and 
one  on  the  derivation  of  VR  t~  e  :  k.  In  both  cases,  we  have  to  use  Fact  2.37  (Splits  are 
Nonempty)  on  page  51  in  the  case  where  the  root  inference  is  split-type  and  the  type  of 
x  is  being  split.  In  logic,  the  “only  if”  case  of  this  theorem  is  called  “weakening”  and  the 
“if  case  is  called  “strengthening”. 

Var-TYPE  is  analogous  to  Var-valid  rule  except  we  add  the  premise  r  c  t.  This 
ensures  that  all  types  we  use  from  the  environment  are  well  formed.  We  state  this  formally 
and  sketch  the  proof  in  Fact  2.48  (Free  Variables  Refine)  on  page  64.  If  this  were  not  true, 
for  many  of  the  theorems  below  we  would  have  to  add  an  assumption  that  all  variables  in 
the  environment  are  well  formed. 

The  differences  between  CASE-TYPE  and  CASE- VALID  have  two  causes.  First,  there  is 
always  exactly  one  t  and  tc  such  that  c  ::  t  <—>  tc,  but  in  general  there  may  be  many  r’s 

dcf 

and  re’s  such  that  c  :  r  «— »  re.  This  causes  the  added  quantification  on  k  in  the  case-type 
rule. 

Second,  we  do  not  want  to  require  unreachable  cases  to  have  a  refinement  type.  If  a  case 
is  never  reachable,  we  do  not  require  it  to  have  a  refinement  type,  so  it  would  not  necessarily 
have  an  ML  type  unless  we  explicitly  required  it  to.  The  last  premise  of  case-type  requires 
the  case  statement  as  a  whole  to  have  an  ML  type,  and  by  case-valid,  this  requires  the 
unreachable  cases  to  have  ML  types. 

There  is  a  natural  analogy  between  instantiating  a  polymorphic  ML  type  and  weakening 
a  refinement  type,  since  both  operations  replace  the  type  by  a  less  informative  type.  The 
analogy  is  not  perfect;  in  particular,  although  there  are  infinite  sequences  of  increasingly 
instantiated  polymorphic  types,  such  as 

straightforward  reasoning  tells  us  there  are  no  infinite  sequences  of  increasingly  weak 
refinement  types:  because  the  refinement  types  are  increasingly  weak,  they  must  be  com¬ 
parable,  so  Theorem  2.21  (Subtypes  Refine)  on  page  36  tells  us  they  all  refine  the  same 
ML  type;  by  Theorem  2.90  (Finite  Refinements)  on  page  1 15,  there  are  only  finitely  many 
distinct  refinements  of  any  ML  type,  so  the  chain  must  be  finite. 

Unfortunately,  standard  notation  obscures  this  analogy.  If  the  refinement  type  r2  is 
weaker  than  the  refinement  type  rt,  we  write  r\  <  r2.  But  in  [DM82],  among  other  places, 
if  the  type  scheme  <r2  is  an  instance  of  the  type  scheme  <t\,  we  write  cr\  >  <r2.  We  make  no 
use  of  the  instantiation  ordering  in  this  thesis,  so  we  are  not  faced  with  a  choice  between 
internal  inconsistency  and  external  inconsistency. 

The  original  Damas-Milner  type  inference  system  [DM821  disallows  instantiating  the 
type  of  the  recursion  variable  in  a  fixed  point  immediately  before  using  it,  and  that  system 
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is  decidable.  The  Milner-Mycroft  type  inference  system  [Myc84]  is  a  variant  that  permits 
instantiating  the  type  of  the  recursion  variables  in  fixed  points,  and  that  change  is  sufficient 
to  make  the  type  system  undecidable  [KTU89].  None  of  these  questions  arise  for  the  ML 
type  inference  we  use  in  this  chapter,  because  there  is  no  polymorphism.  But  the  following 
question  does  arise:  which  of  these  systems  is  refinement  types  analogous  to,  and  how  does 
that  affect  decidability? 

Both  the  Damas-Milner  and  the  Milner-Mycroft  type  systems  distinguish  type  schemes 
(which  can  be  instantiated)  from  types  (which  cannot).  In  the  refinement  type  system, 
WEAKEN-TYPE  can  be  applied  anywhere,  so  all  refinement  types  are  analogous  to  the  type 
schemes  in  polymorphic  type  inference.  In  particular,  the  refinement  type  of  the  recursion 
variable  in  a  fixed  point  can  be  weakened  before  it  is  used.  In  this  sense,  refinement  type 
inference  is  analogous  to  the  Milner-Mycroft  system.  However,  refinement  type  inference 
is  decidable  because  there  the  ML  type  of  the  recursion  variable  is  uniquely  determined, 
and  this  tightly  constrains  the  search. 

If  an  expression  has  a  refinement  type,  then  the  variables  it  uses  have  well-formed  types 
in  the  variable  environment.  This  is  the  refinement  type  analogue  of  Fact  2.5  (ML  Free 
Variables  Bound)  on  page  29.  To  state  it  formally, 

Fact  2.48  (Free  Variables  Refine)  7/VR  e  :  r  and  x  is  free  in  e,  then  there  is  a  t  such 
that  VR(a;)  C  t. 

Proof  of  this  is  by  induction  on  the  derivation  of  VR  he:r. 


2.6.4  Properties  of  Constructors 

This  subsection  describes  the  properties  of  value  constructor  that  are  directly  used  by 
refinement  type  inference.  As  we  mentioned  earlier,  we  say  that  a  constructor  maps  values 
of  type  r  to  values  of  type  rc  by  writing 

def 

c  :  r  ♦  rc. 

For  example,  this  assumption  about  true  fits  its  ordinary  meaning: 

true  df  runit  tt 
as  does  this  assumption  about  false: 

false  d?f  runit  ff. 

If  a  constructor  has  a  refinement  type,  it  also  has  larger  refinement  types,  so  these  assump¬ 
tions  are  also  reasonable: 

•  def  -r- 

true  :  runit  c— ►  T  ioo{ 
false  d?f  runit  c— >  T  ioo{ . 
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a  re’s  such  that  c  :  r  <— >  re.  This  contrasts  with 

pcs  lor  the  bitstring  constructor  Zero: 

Zero  d?f  empty  >  T 

_  def  ,  , 

7  Zero  :  nf  <— >  n/ 

def  ,  -p 

Zero  ;  tij  c  >  I  bitstr 

_  def  _  -r 

•r  Zero  t  '  '  ildjlr 

.re  used  by  refinement  type  inference.  We 
on  “[I”,the  splitting  relation  “x”,  and  the 

ed  :  to  be  consistent  with  . 

ines)  If 


each  constructor  c  there  are  t  and  tc 
instructor  Type  Refines)  on  page  65 


iKes  it  useful  is  Theorem  2.69  (Splitting 
ms  a  type  that  splits,  then  the  value  has 
ihe  form  c  v  and  it  has  the  type  re  that 
lives  a  type  to  c  v  will  first  infer  a  type  for 
r  t— >  re.  We  need  some  way  to  conclude 


•  re,  for  some  i.  This  requirement  is  too  strong 
■-.ample,  if  we  distinguish  even  length  and  odd 

_  !  cons  of  bool  *  blist 
a  \  boot  *  bod  I  nil  ( runit ) 

■3  (T ho„i  *  bev) 


00P7  ATAILABLBTOgggflOii 90S  fJOMU IUUI JMtBLM HJPBODUOI^If 
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we  have 

cons  T  *  Tuut  «-»  T  uut 

and 

T biut  {bev,  bod} 

but  neither 

cons  d?f  T  jaoj  *  T  butt  t— *■  bev 

nor 

cons  d?f  Tioaj  *  T bn,t  <— *  bod. 

Instead,  we  require  for  each  split  of  r,  there  is  a  split  of  rc  such  that  c  maps  each  fragment 
of  r  to  some  fragment  of  rc.  This  seems  to  work  well  for  many  ordinary  examples.  In  the 
above  example,  r  is  Tt<Kl/  *  T Mj„  and  we  have  the  following: 


T to at  *  ^  {Tloat  *  l)CV,  T  bool  *  bod} 

cons  d'f  Tm  *  be v  c— »  bod 
cons  d?f  T  *  bod  <— ►  bev 


This  approach  only  makes  sense  if  a  refinement  type  splits  whenever  it  refines  some 
ML  type.  For  instance,  consider  the  ML  datatype 

datatype  pred  =  A  of  bool  — ►  bool 
|  B  of  bool  — +  bool 


and  the  refinement  type  declaration 

rectype  a  -  A  ( bool  — >  bool ) 
and  b  =  B  (bool  — >  600I) 

The  types  for  the  value  constructors  arising  from  this  are 

A  .'  ( T  bool  ►  T  b00i )  1  >  a 


and 

B  :f  — >  T booi)  b. 

At  this  point  it  seems  reasonable  to  have  TpreJ  x  {o,  6}.  This  would  fail  our  criterion  if 
SELF- SPLIT  did  not  ensure  that  T  baoi  —*  T  boot  splits. 

Putting  this  formally, 

Assumption  2.50  (Split  Constructor  Consistent)  If 

def 

c  :  r  «— ►  rc 
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and 

rc  x  {rci , . . . ,  rcn} 

then  there  is  some  provable  assertion  of  the  form 

r  x  {r,,...  ,rm} 

such  that  for  all  j  between  1  and  m  there  is  an  i  between  1  and  n  such  that 

def 

c  :  rj  <— ►  ra. 


Constructors  and  Intersection  We  will  need 


Assumption  2.51  (Constructor  And  Introduction)  If  c  ?  r  •—>  rc  and  c  :  r  •—+  kc  then 
c  :  r  <->  (rc  A  kc). 

Any  use  of  CONSTR-TYPE  that  uses  a  property  that  only  exists  because  of  Assumption  2.5 1 
(Constructor  And  Introduction)  on  page  67  could  be  replaced  by  two  uses  of  CONSTR-type 

def  , 

followed  by  an  and-introtype  and  then  a  WEAKJEN-TYPE  to  convert  rc  A  kc  to  rc  A  kc. 
We  use  Assumption  2.5 1  (Constructor  And  Introduction)  on  page  67  when  we  do  not  want 
the  derivation  to  have  WEAKEN-TYPE  at  the  root;  this  is  in  the  RCON-AND-ELIM-SUB  case  of 
Lemma  2.67  (Piecewise  Intersection)  on  page  84. 

Constructors  and  Subtyping  We  need  the  assumed  types  for  constructors  to  be  con¬ 
sistent  with  the  subtyping  relation  on  the  left  and  the  assumed  subtyping  relation  on  the' 
right. 


Assumption  2.52  (Constructor  Argument  Strengthen)  If  c  :  r  <-*  rc  and  k  <  r  then 

def  . 

c  :  k  <—>  rc. 

def  def  ilcf 

Assumption  2.53  (Constructor  Result  Weaken)  If  c  :  r  «— »  rc  and  rc  <  kc,  then  c  : 
r  <— » kc. 

Neither  of  these  rules  change  the  set  of  types  that  can  be  inferred  using  CONSTR-TYPE. 
Any  use  of  CONSTR-TYPE  that  uses  a d?  property  that  exists  only  because  Assumption  2.52 
(Constructor  Argument  Strengthen)  on  page  67  requires  it  could  be  replaced  by  a  use  of 
WEAKEN-TYPE  followed  by  a  use  of  CONSTR-TYPE.  Similarly,  any  use  of  CONSTR-type  that 

uses  ad?f  property  that  exists  only  because  Assumption  2.53  (Constructor  Result  Weaken)  on 
page  67  requires  it  could  be  replaced  by  a  use  of  CONSTR-TYPE  followed  by  WEAKEN-TYPE. 

However,  without  these  assumptions,  the  CASE-TYPE  rule  would  have  to  use  where 
it  presently  uses  “d?f”.  This  would  make  several  of  the  proofs  below  much  more  complex, 
since  the  behavior  of  the  constructors  in  CASE- TYPE  would  depend  on  the  results  of  type 
inference  rather  than  depending  simply  upon  our  assumptions. 
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2.7  Compatibility  With  ML 

In  this  section  describe  in  what  sense  refinement  type  inference  is  compatible  with  ML 
type  inference.  Under  very  general  conditions,  all  terms  with  a  refinement  type  have  an 
ML  type.  Also,  under  special  conditions  corresponding  to  complete  absence  of  rectype 
statements,  all  terms  with  an  ML  type  have  a  refinement  type. 

The  first  property  ensures  that  simple  modifications  to  existing  ML  compilers  will 
allow  them  to  compile  programs  that  have  been  checked  with  refinement  types.  The  second 
property  ensures  that  substituting  a  compiler  that  checks  refinement  types  for  one  that 
checks  ML  types  will  not  disorient  naive  users  or  break  existing  code. 


2.7.1  Inferring  an  ML  type  Given  a  Refinement  Type 

The  statement  of  the  theorem  we  intend  to  prove  here  is  very  straightforward.  It  uses  the 
rtom  function  defined  on  page  ^2: 


Theorem  2.54  (Inferred  Types  Refine)  If 

VR  h  e  :  r 


then  there  is  a  t  such  that 


r  C  t 


and 

rtom(VR)  H  e  ::  t. 


The  proof  of  this  is  an  entirely  straightforward  induction  on  the  refinement  type  deriva¬ 
tion.  Explicit  provision  had  to  be  made  in  the  CASE-TYPE  rule  to  make  the  proof  succeed. 
The  problem  is  that  ML  type  inference  for  case  statements  requires  all  subterms  of  the 
case  statement  to  have  an  ML  type,  but  refinement  type  inference  for  case  statements  does 
not  require  subterms  that  are  obviously  unreachable  to  have  a  refinement  type. 

This  arrangement  is  necessary  if  we  want  refinement  type  inference  to  formalize  simple 
case-based  reasoning  humans  routinely  do  when  they  think  about  a  program.  For  instance, 
if  we  assume  that  the  function  f  is  well-behaved  when  passed  true  ()  as  an  argument  but 
not  false  (),  then  we  would  expect  the  expression 

case  x  of 

true  =>  fn  ignored:  bool  =>  f  x 
I  false  =>  fn  ignored:  bool  =>  true  () 
end :  bool 


2. 7.  COMPATIBILITY  WITH  ML 


69 


to  be  well-behaved  whether  x  is  true  ()  or  false  ().  We  can  formalize  this  reasoning  in 
refinement  types  by  giving  f  a  type  which  specifies  no  behavior  when  passed  an  argument 
of  type  ff;  one  such  type  for  f  would  be  tt  — >  ff.  Then  our  assertion  is  that  the  case 
statement  above  should  have  a  refinement  type  even  if  we  give  x  the  type  ff.  Under  these 
assumptions,  the  expression  f  x  has  no  refinement  type,  so  the  rule  for  case  statements 
must  not  require  unreachable  cases  to  have  a  refinement  type. 

If  refinement  type  inference  completely  ignored  the  unreachable  cases  in  case  state¬ 
ments,  then  we  could  make  terms  that  have  a  refinement  type  but  no  ML  type.  For  example, 
if  we  assume  that  x  has  the  refinement  type  ff,  then  the  statement 

case  x  of 

true  =>  fn  ignored:  bool  =>  ()  () 

I  false  =>  fn  ignored:  bool  =>  true  () 
end :  bool 

would  have  a  refinement  type  but  no  ML  type.  To  solve  this  problem,  the  CASE-TYPE 
explicitly  requires  the  case  statement  to  have  an  ML  type. 

There  is  at  least  one  other  way  to  solve  the  problem.  We  could  allow  some  expressions 
to  have  a  refinement  type  but  no  ML  type.  In  that  case  the  best  we  could  do  here  would  be 
to  prove  that  if  an  expression  has  both  a  refinement  type  and  an  ML  type,  the  refinement 
type  refines  the  ML  type.  Many  of  the  theorems  we  prove  below  would  need  to  have  a 
hypothesis  added  to  ensure  that  some  expression  has  an  ML  type.  The  extra  hypotheses 
would  add  bulk  but  no  insight,  so  we  shall  use  the  CASE-TYPE  rule  as  it  stands. 

If  we  eliminated  the  ML  type  after  the  end  keyword  that  determines  an  ML  type  for 
the  case  statement  some  case  statements  would  have  malformed  refinement  types.  For 
example,  the  refinement  type  assigned  to  a  case  statement  where  none  of  the  cases  were 
reachable,  such  as 

case  (fix  f:  bool bool  =>  fn  x:bool  =>  f  x)  ()  of 
true  =>  fn  ( ):tunit  =>  true  () 

I  false  =>  fn  ( ):tunit  =>  false  () 
end 

could  be  a  malformed  refinement  type  such  as  tt  A  (tt  — ♦  tt).  If  we  took  out  the  premise 
r  C  u  from  the  CASE-TYPE  rule,  we  could  infer  this  type  directly;  if  we  left  that  premise  in. 
but  omitted  u  from  the  syntax,  then  we  would  still  be  able  to  use  and- intro-type  to  infer 
this  malformed  refinement  type  for  the  case  statement. 

Without  further  ado,  we  will  prove  Theorem  2.54  (Inferred  Types  Refine)  on  page  68. 
Proof:  By  induction  on  the  derivation  of  VR  h  e  :  r. 

Case:  and-  intro-type  Then  r  has  the  form  r]  A  r2  and  the  premises  of  and- intro- type 
are 

VR  F  e  :  r, 
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and 

VRhe:  r2. 

Applying  our  induction  hypothesis  to  each  of  these  gives  t\  and  t2  such  the  following  hold: 

n  Ci, 

rtom(VR)  h  e  ::  t\ 

r2Ct2 

rtom(VR)  he::  t2. 

Lemma  2.4  (Unique  Inferred  ML  Types)  on  page  27  gives  t\  =  t2,  so  and-ref  gives 

fi  A  r2  C  t\. 

TTiis  and  rtom(VR)  h  e  ::  are  our  conclusions. 

Case:  weaken-type  The  premises  of  WEAKEN-TYPE  must  be 

VR  h  e:k 
and 

k  <  r. 

By  induction  hypothesis,  there  is  a  t  such  that  k\zt  and 

rtom(VR)  h  e  ::  t. 

By  Theorem  2.2 1  (Subtypes  Refine)  on  page  36, 

rCt. 


The  last  two  are  our  conclusion 

Case:  SPLIT-TYPE  Then  VR  must  have  the  form  VR'[x  :=  k]  where  the  premises  of 
split-type  are 

k  x  s 


and 


for  all  p  in  s  we  have  VR'[®  :=  p]  h  e  :  r. 


By  Fact  2.37  (Splits  are  Nonempty)  on  page  51,  a  is  nonempty;  let  p  be  any  element  of  s. 
By  induction  hypothesis. 


r  C  t 


and 

ftom(VR'[x  :=  pj)  h  e  ::  f. 


If  rtom(fc)  is  defined,  then  Corollary  2.32  (Split  Types  Refine  I)  on  page  51  gives 
nom(fc)  =  rtom(p)  so  we  have 


rtom(VR'[*  :=  k ])  h  e  ::  t. 
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This  and  r  C  t  are  our  conclusions. 


If  rtom(fc)  is  undefined,  then  by  a  contrapositive  of  Fact  2.34  (Split  Types  Refine  II)  on 
page  51,  rtom(p)  must  be  undefined  also.  By  definition  of  rtom  applied  to  functions,  this 
implies  rtom(VR'[x  :=  A;])  =  rtom(VR'[x  :=  p]).  Thus  rtom(VR'[x  :=  A;])  F  e  ::  t;  this 
and  r  C  t  are  our  conclusions. 


Case:  var-type 


Then  e  has  the  form  x.  The  premises  of  var-type  are  r  =  VR(x)  and 


r  C.  t.  By  definition  of  rtom  for  functions,  rtom(VR)(x)  =  t,  so  VAR- VALID  immediately 
gives  rtom(VR)  F  x  ::  t,  which  is  our  conclusion. 


Case:  ABS-TYPE  Then  e  has  the  form  f n  x :  t\  =>  e'  and  r  has  the  form  r \ 
premises  of  ABS-TYPE  are 

ri  C  ti 


and 

VR[x  :=  t*i]  h  e'  :  rj- 

Our  induction  hypothesis  gives  a  t2  such  that 


r2  and  the 


r2Ct2 


rtom(VR[x  :=  ri])  h  e  ::  t2. 
rtom(VR[x  :=  r^)  =  rtom(VR)[x  :=  fi] 


and 

Since  ry  Ctlt  we  have 

SO  ABS- VALID  gives 

rtom(VR)  F  fn  x:<(  =>  e' ::  t\  — >t2. 

From  r\  □  t\  and  r2  C  t2  we  can  use  arrow-sub  to  get 

ri  ^r2  C  fi  -*t2. 

The  last  two  displayed  formulae  are  our  conclusions. 

Then  e  has  the  form  el  e2  and  the  premises  of  APPL-TYPE  are 
VR  F  e,  :k^r 


Case:  appl-type 


and 


VR  F  e2  :  k. 


Applying  induction  hypothesis  to  each  of  these  gives  the  following: 

k—*rCu 
rtom(VR)  F  et  ::  u 
k  c  t\ 

rtom(VR)  F  e2  ::  t\ 
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The  only  way  to  infer  k  —*  r  C  u  is  by  using  ARROW-REF  where  u  =  t\  — ► t  and  the  premises 
of  arrow-ref  are  k  c  t 1  and  ret. 

By  Lemma  2.10  (Unique  ML  Types)  on  page  31,  from  k  c  t\  and  k  c  t\  we  can  infer 
t\  =  t\.  Thus  we  can  use  appl- valid  to  get 

rtom(VR)  H  e\  e2  ::  t. 


This  and  r  C  t  are  our  conclusions. 


Case:  CONSTR-TYPE 
of  CONSTR-TYPE  are 


Then  e  has  the  form  c  e'  and  r  has  the  form  rc  where  the  premises 


c 


rc 


and 


VRhe':  k. 


By  Assumption  2.2  (Constructors  have  Unique  ML  Types)  on  page  26,  there  are  unique  u 
and  tc  such  that 

def 

c  ::  u  <—*  tc. 

def 

By  Assumption  2.49  (Constructor  Type  Rennes)  on  page  65,  k  □  u  and  rc  C  tc. 

Our  induction  hypothesis  gives  a  v!  such  that  k  C  u'  and 


rtom(VR)  h  e' ::  u'. 

Since  k  C  u  and  k  □  u\  Lemma  2.10  (Unique  ML  Types)  on  page  31  tells  us  that  u  =  u'. 
Thus  we  can  use  constr- valid  to  get 


rtom(VR)  He  e' ::  tc. 


Choose  t  =  tc.  Since  rc  C  tc,  we  can  use  RCON-REF  to  get 

rc  C  tc. 

The  last  two  displayed  equations  are  our  conclusions. 

Case:  case-type 

Then  e  has  the  form  case  eo  of  c\  ->  e\  I  ...  I  c^  =>  en  en d:t.  Two  of  the 
premises  of  CASE-TYPE  are 

rCt 


and 

rtom(VR)  H  e  ::  f, 

which  are  our  conclusions. 
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Case:  tuple-type 


Then  r  has  the  form  rt  * . . .  *  rn  and  e  has  the  form  (e* ,  . . . ,  en) 


and  the  premises  of  TUPLE-TYPE  are 

for  i  in  1 ...  n  we  have  VR  b  e*  :  r». 

Applying  the  induction  hypothesis  to  each  of  these  gives  ML  types  £  x  through  £„  such  that 

for  t  in  1 ...  n  we  have  r;  C  U 
and 


By  TUPLE-REF, 
and  by  TUPLE- valid. 


for  i  in  1 ...  n  we  have  rtom(VR)  b  e* ::  £». 
r\  *  . . .  *  rn  □  t\  *  . . .  *  tn 


rtom(VR)  H  (ex  *  ...  *  en)  ::  t\  *  . . .  *  tn. 

If  we  choose  t  =  t \  *  . . .  *  f„,  this  is  our  conclusion. 

Then  e  has  the  form  elt_m_n  e'  and  the  premise  of  ELT-TYPE  is 


Case:  elt-type 


VR  b  e' :  r\  *  ...  *rn 

where  r  =  rm.  By  induction  hypothesis,  there  is  a  u  such  that 

and 

rtom(VR)  b  e' ::  u. 

We  can  only  infer  rj  *  . . .  *  rn  C  u  by  using  TUPLE-REF  where  u  has  the  form  u\  *  ...  *  un 
and 

for  i  in  1 ...  n  we  have  r,-  (Z 
Since  u  has  this  form,  we  can  use  ELT- valid  to  get 

rtom(VR)  b  e' ::  tm. 

If  we  choose  t  =  tm,  the  last  two  displayed  formulae  are  our  conclusions. 

Then  e  has  the  form  fix  /:£[— =>  in  x:t\  =>  e' and  the  premises 


Case:  fix-type 


of  FIX-TYPE  are 
and 


r  C  £|  — >  £2 

VR[/  :=  r]  b  f n  x:t\  ->  e' :  r. 
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By  induction  hypothesis,  there  is  a  t  such  that 

r  C  t 


and 

rtom(VR[/  :=  r])  F  fn  x:t\  =>  e'  ::t.  (2.14) 

Since  r  C  t  and r  C  1 1  -*■  t2,  Lemma  2. 10  (Unique  ML  Types)  on  page  3 1  gives  /  =  /,->  /2- 
Since  r  O  t\  -+t2,  the  definition  of  rtom  gives  rtom(VR[/  :=  rj)  =  rtom(VR)[/  := 
t\  — >  t2}.  Thus  we  can  use  Fix- VALID  on  (2.14)  to  get 

rtom(VR)  F  f ix  f\t\^>t2  =>  fn  x\t\  ->  e'  ::tx—*t2 

This  and  r  c  /i  — >  t2  are  our  conclusions.  Q 

Because  of  this,  if  a  value  has  a  refinement  type,  the  form  of  the  refinement  type  gives 
us  information  about  the  form  of  the  value.  We  will  use  this  in  Lemma  2.67  (Piecewise 
Intersection)  on  page  84.  For  example, 

Lemma  2.55  (Value  Arrow  Type)  If  VR  F  v  :  r\  — >  r2  then  v  has  the  form  fn  x :  t  =>  e. 

Proof:  By  Theorem  2.54  (Inferred Types  Refine)  on  page  68,  there  is  a  t  such  that  rt  -» r2  C  t 
and  rtom(VR)  F  v  ::  t.  Since  ri  — ♦  r2  C  t,  we  know  t  has  the  form  t{  — >  t2.  From  the  ML 
type  inference  rules  and  the  possible  forms  of  v,  the  last  inference  of  rtom(VR)  h  v  ::  t 
must  be  abs- valid  and  u  must  have  the  form  fn  x:t  ~>  e.  □ 

Similar  reasoning  gives  results  for  value  constructors  and  tuples: 

Fact  2.56  (Value  Constructor  Type)  //VR  F  v  :  rc  then  v  has  the  form  c  v'. 

Fact  2.57  (Value  TUple  Type)  //VR  F  v  :  r}  * . . .  *  rn)  then  v  has  the  form  (t>i ,. . .  ,vn). 

2.7.2  Inferring  a  Refinement  Type  Given  an  ML  Type 

Some  pieces  of  ML  code  fail  to  have  a  refinement  type  in  the  presence  of  remarkably  few 
rectype  statements.  For  example,  consider  this  program  in  the  formal  language: 

datatype  d  -  C  of  bool  — >  bool 
case  C  (fn  xibool  =>  x)  of 

C  =>  fn  y: bool-*  bool  =>  (y  (true  ())) 
end:  bool 

The  case  statement  has  the  ML  type  bool.  In  the  absence  of  any  rectype  statements,  the 
ML  type  bool  has  only  one  refinement,  which  we  can  call  T  The  type  of  the  case 
statement  is  T 

However,  if  we  insert  this  rectype  statement  before  the  datatype  declaration: 
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rectype  tt  =  true  ( runit ) 
and  ff  -  false  (runit) 

the  following  argument  tells  us  the  case  statement  no  longer  has  a  refinement  type. 

Informally,  the  problem  is  that  the  constructor  C  loses  all  information  about  its  argument. 
Thus  type  inference  has  to  make  the  assumption  that  y  can  have  any  refinement  type 
whatsoever.  The  worst  case  is  a  function  that  cannot  be  called  legitimately  with  any  value. 
Since  we  call  y  with  a  value,  we  fail. 

The  reader  may  object  at  this  point  that  we  cannot  construct  any  function  that  cannot 
be  called  with  any  value.  This  is  true,  but  in  Chapter  6  when  we  introduce  the  explicit 
refinement  type  declaration  operator  <,  we  will  be  able  to  write  such  expressions.  One  of 
them  is: 


fn  xibool  ->  (x  <d  i.40<,i). 


We  can  also  give  a  formal  argument  that  the  case  statement  has  no  type.  Let  us  suppose 
that  the  case  statement  had  the  refinement  type  r,  and  try  to  construct  the  type  derivation. 
The  conclusion  would  clearly  be 


f-  case  . . .  end  :  r. 


Since  r  is  arbitrary,  we  might  as  well  assume  the  last  inference  in  the  derivation  is  CASE- 
TYPE  rather  than  and- intro-type  or  WEAKEN-TYPE.  If  we  use  T  d  as  the  name  for  the 
unique  refinement  of  d,  the  first  premise  of  CASE-TYPE  must  have  the  form 

HC  (fn  xibool  ->  x)  :Tj. 


The  second  premise  is 


Td  C  d, 

which  is  trivial.  The  third  premise  says  that  whenever  C  :  k  ^  T d,  we  must  have 
h  fn  y :  bool  — >  bool  =>  (y  (true  ( ) ) )  :  k  — ►  r. 


Choose  k  —  -l- b00i  — >  T booi ■  By  Lemma  2.68  (Subtype  Irrelevancy)  on  page  88,  if  we  can 
derive  this  we  can  do  it  with  ABS-TYPE  as  the  root  inference.  The  premise  of  abs-TYPE 
must  be 

y  :  -Lbool  -*  T ioot  h  y  (true  () )  :  r 
and  this  requires  using  appl-TYPE  with  the  premise 

y  :  l4o<,/  -*•  T bool  I"  true  ()  :  1  booi 


which  is  not  derivable. 

We  can  get  the  case  statement  to  typecheck  by  adding  a  rectype  statement  so  C  does 
not  lose  all  information  about  its  argument.  One  possible  addition  would  be 
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rectype  total  =  C  (Ti,,,/  — » 

With  this  addition,  there  are  now  two  refinements  of  the  ML  type  d ,  namely  T i  and 
total.  A  principal  type  of  C  (fn  x:bool  =>  x)  is  total.  (It  also  has  the  principal  type 
total  A  total,  among  infinitely  many  others;  we  will  eventually  show  that  all  principal  types 
are  equivalent.)  The  case  statement  gets  the  type  T 4^. 

Generalizing  from  this  example,  if  we  allow  the  programmer  to  specify  any  refinement 
type  distinctions,  there  may  be  expressions  with  an  ML  type  but  no  refinement  type.  Thus 
we  shall  assume  for  the  duration  of  this  subsection  that  the  programmer  has  made  no 
refinement  type  distinctions,  and  we  shall  prove  that  any  expression  with  an  ML  type  also 
has  a  refinement  type.  More  formally,  our  temporary  assumption  is  that  each  ML  type 

def 

constructor  tc  has  exactly  one  refinement,  and  we  will  call  that  refinement  mtor(tc). 


utl  uwi  .  uti 

Assumption  2.58  (mtor  Refines)  For  all  tc  we  have  mtor( tc)  E  tc. 


Assumption  2.59  (Only  mtor  Refines)  (assumed  for  this  subsection  only)  For  all  tc  and 
•  •  def  .  def  ,  . 

all  rc,  ifrc  E  tc  then  rc  =  mtor( tc). 

We  then  lift  this  construction  in  the  natural  way  to  refinements  of  general  ML  types: 

Definition  2.60  We  define  mtor  as  the  function  mapping  ML  types  to  refinement  types  that 
is  consistent  with  the  following  equations: 

mtor(rc)  =  mtor(fc) 
mtor(fi  — >t2)  =  mtor(ti')  — ►mtor^) 
mtor(ii  *  =  mtor(ti)  *  ...  *  mtor(i„). 

We  extend  mtor  pointwise  to  operate  on  environments  such  as  VM. 

Trivial  inductions  on  t  give: 

Fact  2.61  (mtor  Refines)  For  all  t  we  have  mtor(i)  E  t. 

Fact  2.62  (Unique  Refinement)  Ifr  E  t  then  r  =  mtor(t). 

Now  we  have  enough  notation  to  state  that  the  value  constructors  behave  properly: 
Assumption  2.63  (Constructor  mtor  Consistent)  If 

def 

c  ::  1 tc 


c  d?f  mtor(t) c— ►  mtor(tc). 


then 
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In  the  absence  of  any  of  the  type  declarations  introduced  in  the  next  chapter,  these  con¬ 
ditions  are  satisfied  trivially  because  each  ML  type  constructor  has  exactly  one  refinement. 
Each  value  constructor  maps  the  unique  refinement  of  its  domain  to  the  unique  refinement 
of  its  range. 

Under  these  assumptions,  we  can  show  that  each  program  with  an  ML  type  t  has  the 
refinement  type  mtor(<): 

Theorem  2.64  (ML  Compatibility)  If 

VM  h  e  ::  u 

then 

mtor(VM)  h  e  :  mtor(u). 

Proof:  Straightforward,  by  induction  on  the  derivation  of  the  hypothesis. 

Case:  Var-valid  Then  e  —  x  and  u  =  VM(x).  Using  vaR-TYPE  gives  mtor(VM)  h  x  : 
mtor(u),  which  is  our  conclusion. 

Case:  abs- valid  Then  e  =  fn  x:l|  =>  e'  and  t2.  The  premise  of  abs- valid 

must  be 

VM[x  :=  ti]  h  e' ::  t2. 

Fact  2.61  (mtor  Refines)  on  page  76  gives 

mtor(*t)  C  t\. 

Our  induction  hypothesis  gives 

mtor(VM[x  :=  t\ j)  F  e' :  mtor(t2). 

Since  mtor(VM[x  :=  t\ ])  =  mtor(VM)[x  :=  mtor(fi)],  we  can  use  abs-type  to  get 
mtor(VM)  h  fn  x:t\  =>  e' :  mtor(fi) -»mtor(t2). 

Since  mtor(ti)  — >  mtor(i2)  =  mtor(ti  — >  t2),  this  is  our  conclusion. 

Case:  appl- valid  Then  e  =  e\  e2  and  the  premises  of  appl- valid  are 

VM  b-  e\  ::  t  — >u 


and 


VM  F  e2  ::  t. 
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Applying  the  induction  hypothesis  to  each  of  these  gives 

mtor(VM)  b  t\  :  mtor(£  —*  u) 
and 

mtor(VM)  b  e2  :  mtor(t). 

Since  mtor(u  — ►  t)  =  mtor(t)  — >  mtor(u),  we  can  use  appl-type  to  get 

mtor(VM)  b  tx  e2 :  mtor(u), 

which  is  our  conclusion. 

Then  t  —  ce'  and  u  =  tc  and  the  premises  of  CONSTR-valid  are 


Case:  constr-valid 


def  .  . 

c  :  t tc 


and 


VM  h  e  ::  t. 

Assumption  2.63  (Constructor  mtor  Consistent)  on  page  76  gives 

c  mtor (t)  <-»  mtor( tc) 

and  our  induction  hypothesis  gives 

mtor(VM)  t~  e' :  mtor(t). 

Using  CONSTR-TYPE  gives 

def 

mtor(VM)  bee':  mtor(tc). 

def 

Since  mtor(  tc)  =  mtor(tc),  this  is  our  conclusion. 


Case:  case- valid 


Then  e  =  case  eo  of  ci  =>  e\ 
premises  of  CASE- VALID  are 

VM  b  e0  ::  tc, 

def 


Cn  =>  en  end  :u  and  the 


for  all  i  we  have  ^  ::  U  t-+  tc, 


and 


for  all  i  we  have  VM  b  ei ::  — *■  tt. 

The  induction  hypothesis  gives  the  first  premise  of  case-type: 


mtor(VM)  b  eo  :  mtor(  tc) 
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Fact  2.61  (mtor  Refines)  on  page  76  gives  the  second  premise  of  case-type: 

mtor(u)  C  u 

def  def 

Suppose  i  and  k  are  given,  and  that  Cj  :  k  t->  mtor(  tc).  Then  Assumption  2.49  (Constructor 
Type  Refines)  on  page  65,  k  □  t{,  and  Fact  2.62  (Unique  Refinement)  on  page  76  give 
k  =  mtor(f<).  Our  induction  hypothesis  gives 

mtor(VM)  F  e;  :  mtor(fi  — ♦  u). 

By  the  definition  of  mtor,  we  have 

mtor(VM)  F  e,  :  mtor(^)  —►mtor (u). 

By  ARROW-SUB  and  k  =  mtor(fi)  we  have  A:-»mtor(u)  =  mtor(fj)  — > mtor(u).  Thus 
WEAKEN-TYPE  gives 

mtor(VM)  F  e< :  k  — »mtor(u). 

Since  this  argument  works  for  any  i  and  k,  the  third  premise  of  CASE-TYPE  holds,  so  we 
have  our  conclusion: 

mtor(VM)  F  (case  e0  of  C|  =>  e\  I  ...  |  c„  =>  en  end:u)  :  mtor(u) 

Case:  TUPLE-VALID  Then  e  has  the  form  (ei ,  . . . ,  en)  and  u  has  the  form  tx  *  . . .  *  tn. 
The  premise  of  TUPLE- valid  must  be 

for  all  i  we  have  VM  F  e{  ::  L. 

Our  induction  hypothesis  gives 

for  all  i  we  have  mtor(VM)  F  e< :  mtor(fi). 

Tuple-type  then  gives 

mtor(VM)  F  (et ,  ...»  en)  :  mtor(fi)  *  ...  *  mtor(f„) 

which  is  our  conclusion  since  mtor(*i)  *  ...  *  mtor(f„)  =  mtor(ft  *  ...  *  tn). 

Case:  ELT- VALID  Then  e  has  the  form  elt  jm_n  e'  and  u  —  tm,  where  the  premise  of 
ELT- VALID  is 

VM  e' ::  t\  *  ...  *  tn. 

Our  induction  hypothesis  gives 


mtor(VM)  F  e' :  mtor(ii  *  ...  *  tn). 
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Since  mtor(ii  *...*$„)  =  mtor(<i  )*...*  mtor(in),  we  can  use  this  as  the  premise  to 
ELT-TYPE  to  get 

mtor(VM)  l~  e It _m_n  e' :  rntor(£m), 


which  is  our  conclusion. 

Then  e  has  the  form  fix  f:t\— >t2  =>  fn  x:ty  =>  e'  and  u  has  the 


Case:  FIX- VALID 


form  t\—*t2.  The  premise  of  Fix- valid  is 

VM[/  :=  t\  —*t2\  h  (fn  x:t\  =>  e')::t\^t2. 


Fact  2.61  (mtor  Refines)  on  page  76  gives 

mtor(*i  — >  t2)  c  t\  -* 12. 


Our  induction  hypothesis  gives 

mtor(VM[/  :=  t\  — *•  *2])  F  (fn  x:t\  =>  e') :  mtor(fi  -*t2). 

Since  mtor(VM[/  :=  t\  — » t2 ])  =  mtor(VM)[/  :=  mtor(ti  -» ^2)].  we  can  use  FIX-TYPE  to 
get 

mtor(VM)  I- fix  f:t\—*t2  =>  fn  x:t\  =>  e' :  mtor(VM) 
which  is  our  conclusion.  □ 


2.8  Simple  Soundness  Proof 

Now  we  are  almost  in  a  position  to  prove  that  this  type  system  is  sound  in  an  appropriate 
sense.  But  first  we  must  prepare  the  way  with  some  lemmas. 

First  we  will  show  that  as  the  assumptions  in  the  environment  get  stronger,  the  set  of 
types  we  can  infer  gets  no  smaller.  At  first  glance  this  seems  fairly  straightforward:  Pick 
a  type  derivation  that  we  can  infer  in  the  weaker  environment;  to  rewrite  it  to  work  in  the 
stronger  environment,  just  replace  all  uses  of  var-type  by  a  use  of  var-type  followed 
by  weaken-type,  and  leave  the  rest  of  the  derivation  the  same.  Unfortunately,  this  proof 
sketch  does  not  handle  uses  of  the  split-type  rule  in  the  original  derivation.  Dealing  with 
SPLIT-TYPE  is  possible  though;  see  that  case  of  the  following  proof. 

The  refinement  type  inference  rules  AND-INTRO-TYPE,  weaken-type,  and  SPLIT-TYPE 
have  the  same  expression  in  their  premise  that  they  have  in  their  conclusion.  All  of  the 
other  refinement  type  inference  rules  have  smaller  expressions  in  the  premises  than  they 
have  in  their  cone!  asion.  We  say  that  the  latter  rules  make  “syntactic  progress”.  It  is  often 
useful  to  know  that  the  root  inference  of  a  derivation  of  a  refinement  type  for  an  expression 
makes  syntactic  progress  because  then  the  form  of  the  expression  uniquely  determines 
which  refinement  type  inference  rule  was  used.  Therefore  we  define  this  special  notation 
to  say  that  the  root  inference  of  a  type  derivation  makes  syntactic  progress: 


2.8.  SIMPLE  SOUNDNESS  PROOF 


81 


Definition  2.65  // VR  H  e  :  r  and  there  is  a  derivation  of  this  that  has  a  rule  other  than 
AND- INTRO-TYPE,  WEAKEN-TYPE,  or  SPLIT-TYPE  at  the  root,  then  we  say  VR  H-  e  :  r. 

We  can  think  of  Lemma  2.66  (Environment  Modification)  on  page  81  as  an  algorithm 
that  maps  a  type  derivation  in  the  weaker  environment  to  a  type  derivation  in  the  stronger 
environment.  This  algorithm  is  more  useful  if  the  output  is  a  type  derivation  that  makes 
syntactic  progress  at  the  root  whenever  possible.  This  is  when  the  original  type  derivation 
makes  syntactic  progress  and  the  expression  is  not  a  variable.  This  optimization  is  reflected 
in  the  theorem  by  the  additional  hypotheses  and  conclusion  after  the  phrase  “Also,  if  in 
addition”. 


Lemma  2.66  (Environment  Modification)  If 

VR  H  e  :  r 


and 

and 

then 

Also,  if  in  addition 
and 

then 


VR'  has  the  same  domain  as  VR 
for  xfree  in  e  we  have  VR'(«)  <  VR(z) 
VR'  h  e  :  r. 

VRH-e  :  r 

e  is  not  a  variable 

VR'  H-  e  :  r. 


Proof:  By  induction  on  the  derivation  of  VR  h  e  :  r.  Some  cases  apply  omy  if  VR  r  e  :  r; 
other  cases  apply  if  either  VR  h  e  :  r  or  VR  H-  e  :  r.  We  will  put  the  cases  that  apply  only 
if  VR  he:r  first. 


Case:  SPLIT-TYPE 
split-type  are 


Then  there  is  a  y  such  that  VR 


k  >c  a 


VRi[y  :=  &]  and  the  premises  of 


and 


for  p  in  s  we  have  VRi  [y  p]  H  e  :  r. 


We  take  cases  on  whether  y  is  free  in  e. 
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SubCase:  y  not  free  in  e 


Thus  VR'  =  VR',[y  :=  k'\  where 


for  all  x  free  in  e  we  have  VR',(z)  <  VR,(;c). 

Therefore,  trivially, 

for  all  x  free  in  e  we  have  VR',[p  :=  k](x)  <  VR,[y  :=  fc](x). 
Our  induction  hypothesis  gives 

VR',[p  :=  k\  he  :  r. 

Fact  2.47  (Non-free  Variables  are  Ignored)  on  page  63  gives 

VR',  he:r, 

and  then  Fact  2.47  (Non-free  Variables  are  Ignored)  on  page  63  again  gives 

VR',  [p  :=  k']  h  e  :  r, 


which  is  our  conclusion. 


SubCase:  y  free  in  e  Thus  VR'  =  VR',  [y  :=  k ']  where 


k'  <  k 


and 


for  x  other  than  y  free  in  e  we  have  VR',(x)  <  VR,(x). 
By  Lemma  2.43  (Split  Intersection)  on  page  54, 

k  A  k1  ^  {p  A  k'  |  p'  6  a}. 


Since  k'  <  k,  we  know  that  k  A  k'  =  k'.  Thus  EQUIV-SPLIT-L  gives 

k'  x  {p1  A  k'  |  p'  G  a}. 

Since  p'  A  k'  is  always  a  subtype  of  p'  when  p'  is  in  a,  it  follows  that,  for  all  p'  in  a  and  all 
x  free  in  e, 

VR',  [y  :=  p'  A  k')(x)  <  VR,[p  :=  p'](x). 

Thus  we  can  use  our  induction  hypothesis  to  conclude 

for  all  p'  in  a  we  have  VR',  [y  :=  p'  A  ft']  h  e  :  r 

Then  we  can  use  split-type  to  get 


YR\[y  :=  A']  heir, 
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which  is  our  conclusion. 

Case:  VAR-TYPE  Then  e  has  the  form  x,  and  VR(x)  =  r.  Since  x  is  free  in  e,  we  must 
have  VR'(x)  <  r.  Var-type  gives 

VR'  h  x  :  VR'(x) 

and  then  weaken-type  gives 

VR'  h  x  :  r, 

which  is  our  conclusion. 

Case:  and-intro-type 

Case:  WEAKEN-TYPE 

Since  neither  of  these  rules  use  or  modify  the  variable  environment,  these  cases  are  trivial. 
Now  we  will  give  the  cases  that  apply  when  e  is  not  a  variable  and  VR  H-  e  :  r. 

Case:  abs-TYPE  Then  e  has  the  form  fn  x:t\  ->  e'  and  r  has  the  form  rt  — ♦  r2.  The 
premises  of  ABS-TYPE  must  be 

and 

VR[x  :=  rj]  h  e' :  r2. 

Self-sub  gives  rj  <ry,  so  we  can  use  our  induction  hypothesis  to  get 

VR'[x  :=  rj]  h  e  :  r2. 


Then  ABS-TYPE  gives 

VR'  H- fn  x:fj  =>  e':r\— >r2, 

which  is  our  conclusion. 

Case:  FIX-TYPE  Then  e  has  the  form  fix  ->  fn  y:t\  =>  e'  and  the  premises 

of  FIX-TYPE  are 

T  C  t\  — >t2 
and 

VR[/  :=  r]  h  fn  y:t\  =>  e' :  r. 

Self- SUB  gives  r  <  r,  so  we  can  use  the  induction  hypothesis  to  get 

VR'[/  :=  rj  h  fn  y:t\  =>  e' :  r 


and  then  FIX-TYPE  gives 


VR'  h  fix  =>  fn  y\t\  =>  e' :  r, 
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which  is  our  conclusion. 

Case:  any  other  inference  rule  The  remaining  inference  rules  do  not  reference  or  modify 

the  variable  environment,  so  all  remaining  cases  are  trivial.  □ 

We  already  explicitly  take  the  subtype  relation  into  account  in  the  weaken-type  rule. 
Our  next  lemma  tells  us  that  the  subtype  relation  also  describes  the  behavior  of  derivations 
that  do  not  end  with  WEAKEN-TYPE.  This  will  allow  us  to  eliminate  uses  of  weaken- 
TYPE  from  the  root  of  type  derivations  for  values  in  Lemma  2.68  (Subtype  Irrelevancy)  on 
page  88. 


Lemma  2.67  (Piecewise  Intersection)  If  for  alii  in  1 . . .  n  we  have 

•  H -v:k{ 


and 


k\  A  ...  A  kn  <  ri  A  . . .  A  rm 


and  none  of  the  r;’s  or  ki’s  are  themselves  intersections  of  other  types,  then  for  all  j  in 
1 ...  m  we  have 


•  H-  v  :  Tj. 


Proof:  By  induction  on  the  derivation  of  ki  A  . . .  A  kn  <  r,  A  . . .  A  rm. 

Case:  SELF-SUB  Then  our  hypothesis  is  our  conclusion. 

Case:  AND-ELIM-R-SUB  Then  n  >  m  and  for  i  in  1 ...  m  we  must  have  r{  =  k{,  o  our 
hypothesis  immediately  implies  our  conclusion. 

Case:  AND-ELIM-L-SUB  Then  n  >  m  and  for  i  in  1 ...  m  we  have  n  =  so  once 

again  our  hypothesis  immediately  implies  our  conclusion. 

Case:  and-intro-sub  Then  there  is  an  h  such  that  the  premises  of  and-intro-SUB  are 

k\  A  ...  A  kn  <r\  A  ...  A  rh 


and 


k\  A  . . .  A  kn  <  rh+\  A  ...  A  rn. 


Using  the  induction  hypothesis  on  each  of  these  gives 


for  j  in  1 . . .  h  we  have  •  H ~v  :  rj 


and 


for  j  in  (h  -I- 1 ) ...  m  we  have  •  H-  v  :  rj. 
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Together  these  are  our  conclusion. 

Case:  TRANS-SUB  Then  the  premises  of  TRANS-SUB  have  the  form 

k\  A  ...  A  kn  <  pi  A  ...  A  pq 

and 

pi  A  ...  Ap,  <  ri  A  ...  A  rm. 

Using  our  induction  hypothesis  on  the  first  of  these  gives 

for  h  in  1 ...  q  we  have  •  B-  v  :  ph 

and  then  using  it  on  the  second  gives 

for  j  in  1 ...  m  we  have  •  H-  v  : 

which  is  what  we  wanted  to  show. 

Case:  ARROW-SUB  Then  n  —  m  —  1  and  k\  has  the  form  k—*k'  and  ri  has  the  form 

r  — > r'.  By  Lemma  2.55  (Value  Arrow  Type)  on  page  74,  v  has  the  form  in  x:t  =>  e. 
Thus  the  last  inference  of  •  H-  v  :  k  — *  k'  is  ABS-TYPE,  where  the  premises  of  ABS-TYPE  are 

[a  :=  fc]  I-  e  :  k' 


kC.t. 

Lemma  2.66  (Environment  Modification)  on  page  8 1  and  r  <  k  gives 


and  WEAKEN-TYPE  gives 


Then  we  can  use  ABS-TYPE  to  get 


[x  :=  r]  h  e  :  k' 


[x  :=  r]  I-  e  :  r'. 


■  t-  fn  x  :t  =>  e  :  r  —*r', 


which  is  our  conclusion. 


Case:  arrow- and-elim-sub  Then  n  =  2  and  m  =  1.  The  form  of  arrow- and-elim- 

SUB  tell  us  fci  A  hi  has  the  form  Pi  — ►  ?2  A  pi  — *  pi  and  rx  has  the  form  pt  ~*(pz  A  pi).  Our 
hypothesis  tells  us 

•  B-  w  :  pi  — >  pz  (2.15) 


H-  v  :  pi  -+P3- 


(2.16) 
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By  Lemma  2.55  (Value  Arrow  Type)  on  page  74,  v  has  the  form  f n  x :  t  ->  e,  so  the  last 
inference  of  both  (2.15)  and  (2.16)  must  be  ABS-TYPE  with  the  following  premises: 

Pi  C  t 

[x  :=  pi]  K  e  :  p2 

[*  -=  Pi]  e  :  P3 

Using  and- intro-type  on  the  last  two  of  these  gives 

[®  :=pi]  H  e  :  P2  Ap3, 


and  then  ABS-TYPE  gives 


■hfn  =>  e  :  pi  — »(p2  A  p$), 


which  is  our  conclusion. 


Case:  rcon-sub 


Then  n  =  m  =  1  and  has  the  form  rc  and  fci  has  the  form  kc.  The 


premise  of  RCON-SUB  must  be  kc  <  rc.  By  Fact  2.56  (Value  Constructor  Type)  on  page  74, 
v  has  the  form  c  v',  so  the  last  inference  in  our  hypothesis  must  be  constr-TYPE.  The 
premises  of  constr-TYPE  must  be 


c 


def 


r  <— >  kc 


and 


•  \~  v' 


Assumption  2.53  (Constructor  Result  Weaken)  on  page  67  gives 


def  • 

c  :  r 


*— ►  rc 


and  then  CONSTR-TYPE  gives 
which  is  our  conclusion. 


Case:  rcon-and-elim-sub 


H-  c  v'  :  rc 


Then  n  =  2  and  m  =  1.  The  shape  of  RCON-AND-ELIM- 

def 


SUB  tells  us  that  kx  A  hi  has  the  form  Aci  A  kc2,  and  rt  is  kc\  A  kc2.  By  Fact  2.56 
(Value  Constructor  Type)  on  page  74,  v  has  the  form  c  v',  so  the  last  inference  of  the 
type  derivations  in  our  hypothesis  must  be  CONSTR-TYPE.  The  premises  of  the  uses  of 
CONSTR-TYPE  must  be 


def 


kc\ 


def 


kc2 


•hr/:  r(. 
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And- intro-type  gives 


•  h  v* :  rj  A  r2. 


Two  uses  of  Assumption  2.52  (Constructor  Argument  Strengthen)  on  page  67  give 


c  d'f  (r[  A  r2 )  *-♦  key 


and 


*:«A  r'2)^ke2, 

and  then  using  Assumption  2.5 1  (Constructor  And  Introduction)  on  page  67  on  these  gives 


def 


c  d*f  (r(  A  7*2 )  £— >  ( key  A  Jbc2). 


Then  CONSTR-type  gives 
which  is  our  conclusion. 


def 


■  hi-  C  v'  :  key  A  ic2, 


Case:  TUPLE-SUB 


Then  m  =  n  =  1  and  ky  has  the  form  k[  *  ...  *  k'  and  ry  has  the  form 
r[  *  ...*  rq.  The  premises  of  TUPLE-SUB  are 

for  h  in  1 ...  q  we  have  k'h  <  r'h. 

By  Fact  2.57  (Value  Tuple  Type)  on  page  74,  v  has  the  form  (t>t  ,...,vq).  Thus  the  last 
inference  of  •  H-  v  :  ky  must  be  TUPLE-TYPE  and  the  premises  of  TUPLE-TYPE  are 


Then  weaken-type  gives 

and  TUPLE-TYPE  gives 
which  is  our  conclusion. 


for  h  in  1 ...  q  we  have  •  h  vh  :  k'h. 

for  h  in  1 ...  q  we  have  •  I-  v/i :  r'h 
•  H-  («t »  •  •  ■ .  v,) :  r\  *  . . .  *  r'q , 


Case:  TUPLE- AND- EL IM-SUB 


Then  n  =  2  and  m  =  1.  By  the  shape  of  tuple- and-elim- 


SUB,  ky  A  &2  must  have  the  form 


(k[  *...*&')  A  (A"  *  ...  *  k'q) 

and  rj  is 

By  Fact  2.57  (Value  Tuple  Type)  on  page  74,  v  must  have  the  form  (t>i  ,  . . . ,  u,)  and  the 
last  inference  of  the  type  derivations  in  our  hypothesis  must  be  TUPLE-TYPE.  The  premises 
of  the  uses  of  TUPLE-TYPE  must  be 


for  h  in  1 ...  q  we  have  •  F  vh  :  k'h 
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and 


for  h  in  1 ...  q  we  have  •  t-  :  k 
Using  AND- INTRO-TYPE  on  these  gives 

for  h  in  1 ...  q  we  have  •  h  :  k'h  A 

and  then  TUPLE-TYPE  gives 


...»  vq)  :  (k[  A  fc")  *...*(&'  A  A"), 


which  is  our  conclusion.  □ 

The  previous  lemma  told  us  that  we  can  eliminate  WEAKEN-TYPE  from  the  root  of 
derivations  of  a  type  for  a  value  in  an  empty  environment.  The  next  lemma  makes  the 
simple  observation  that  we  can  eliminate  AND- INTRO-TYPE  also,  if  the  type  is  not  an 
intersection.  SPLIT-TYPE  cannot  arise  because  the  environment  is  empty,  so  we  can  always 
make  syntactic  progress  at  the  root  of  a  derivation  of  a  non-intersection  type  for  a  value. 

Lemma  2.68  (Subtype  Irrelevancy)  If 


•  h  v  :  r\  A  . . .  A  rn 

where  none  of  the  rfs  are  intersections  then  for  alii  in  \  ...n  we  have 

•  If -v  :  r{. 


Proof:  By  induction  on  the  derivation  of  our  hypothesis. 

Then  there  must  be  an  h  such  that  the  premises  of  and-intro- 

•  b  v  :  r\  A  . . .  A  Th 


Case:  and-intro-type 


TYPE  are 


and 

•\-  v  :  rh+i  A  ...  A  rn. 

Applying  the  induction  hypothesis  to  the  first  of  these  gives,  for  j  in  1 . . .  h, 

•  H-  v  :  rj. 


The  induction  hypothesis  applied  to  the  second  of  these  gives  the  same  for  j  in  (h.  + 1 ) . . .  n, 
so  the  two  of  these  are  our  conclusion. 


Case:  weaken-type 


For  some  r',  the  premises  of  WEAKEN-TYPE  must  be 


•  h  v  :  r' 
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Any  r'  must  have  the  form  rj  A  ...  A  r'm,  where  none  of  the  r'  are  intersections.  By  our 
induction  hypothesis,  for  j  n  1 ...  m  we  have 

•  H~  v  :  r'j. 

Then  Lemma  2.67  (Piecewise  Intersection)  on  page  84  gives,  for  j  in  1 ...  n, 

•  H-  v  :  rj , 


which  is  our  conclusion. 


Case:  split-type 


This  inference  rule  requires  a  nonempty  variable  environment,  which 


we  do  not  have.  Thus  this  case  cannot  happen. 


Case:  var-type 


Case:  appl-type 


Case:  case-type 


Case:  elt-type 


Case:  fix-type 

All  of  these  rules  only  apply  to  non-values,  and  v  is  a  value.  Thus  these  cases  cannot 
happen. 

Case:  abs-type 


Case:  constr-type 


Case:  TUPLE-TYPE  j 

In  these  cases,  n  =  1  and  the  last  inference  of  our  hypothesis  is  neither  and- intro-type 
nor  WEAKEN-TYPE.  Thus  our  hypothesis  is 


•  If-  v  :  rj, 


which  is  our  conclusion.  □ 

Now  we  will  show  that  the  x  relation  behaves  as  one  would  intuitively  expect:  If  a 
value  has  a  type  that  splits,  then  it  has  one  of  the  fragments  as  a  type.  Formally,  we  have 
the  following  theorem: 

Theorem  2.69  (Splitting  Value  Types)  Ifk  x  s  and  -  I -  v  :  k,  then  there  is  an  r  in  s  such 
that  -  I -  v  :r. 
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Proof:  By  induction  on  the  derivation  of  k  x  s. 

Case:  RCON-SPLIT  Then  k  has  the  form  kc  and  all  elements  of  s  are  refinement  type 

constructors.  The  only  possible  form  for  v  is  c  v'.  By  Lemma  2.68  (Subtype  Irrelevancy) 
on  page  88, 

•  H-  c  v' :  kc. 

The  last  inference  of  this  must  be  CONSTR-TYPE  with  the  premises 


and 

•  h  v' :  p. 

By  Assumption  2.50  (Split  Constructor  Consistent)  on  page  66,  there  is  an  s'  such  that 

p  x  s',  and  for  all  p'  6  s'  there  is  a  kc'  €  s  such  that  c  df  p'  >  kc'.  Since  p  x  s',  our 
induction  hypothesis  gives  a  p'  €  s'  such  that 

•  h  v  :  p' . 

Let  kc'  be  an  element  of  s  such  that  c  d?f  p'  <—*  kc'.  Then  CONSTR-TYPE  gives 

•  he  v' :  kc', 

which  is  our  conclusion. 

Case:  TUPLE-SPLIT  Then  there  must  be  an  h  and  a  q  such  that  k  has  the  form  A;,  *  ...  * 
kh-i  *  kh*  kh+ 1  *  ...*  kq  and  kh  x  s'  and 

s  =  {k\  *  ...  *  kh~ i  *p*  kh+ 1  *  ...*kq  |  p  e  s'}. 

By  Lemma  2.68  (Subtype  Irrelevancy)  on  page  88, 

•H -v  :  ki*  ...*  kh-\  *  kh*  kh+ 1  *  ...*  kq.  (2.17) 

By  Fact  2.57  (Value  Tuple  Type)  on  page  74,  v  has  the  form 

(Ul»  ...»  Vh-l,  Vh,  Vh+ 1,  ...»  vq) 

and  the  last  inference  of  (2.17)  must  be  TUPLE-TYPE.  The  premises  of  TUPLE-TYPE  must  be 

for  j  in  1 ...  q  we  have  •  h  vj  :  kj. 

By  induction  hypothesis,  there  is  a  p  is  s'  such  that 

•  1“  vh  :  p. 
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Then  tuple-type  gives 

•  I-  v  :  k\  *  . . .  *  kh-\  *p*  kh+ 1  * ...  *  kq, 
which  is  our  conclusion. 

Case:  TRANS-SPLIT  Then  our  hypothesis  is  A:  x  3i  U  32  where  the  premises  of  trans- 

SPLrr  are  k  x  3j  U  {p}  and  p  x  32.  By  our  induction  hypothesis,  there  is  a  k'  in  3)  U  {p} 
such  that 

■\-v:k'. 

If  k'  6  3j  this  is  our  conclusion;  otherwise  k'  =  p  and  another  use  of  our  induction 
hypothesis  gives  a  k"  e  s2  such  that 

•hs:  k\ 

which  is  our  conclusion. 

Case:  equiv-split-L  The  premises  of  EQUIV-SPLIT-L  must  be  k  =  p  and  p  x  s  for  some 

p.  Weaken-Type  gives  •  h  v  :  p,  and  then  our  induction  hypothesis  gives  an  r  in  3  such 
that 

•  1-  v  :  r, 

which  is  our  conclusion. 

Case:  EQUlV-SPLrr-R  Then  there  is  a  p  such  that  3  =  s'  U  {p}  and  the  premises  of  equiv-- 

SPLIT-R  are  p  =  p'  and  Axi'U  {p'}  for  some  p'.  By  induction  hypothesis,  there  is  some  r 
in  3'  U  {p'}  such  that 

•  t-  v  :  r. 

If  r  is  in  s'  then  we  are  done;  otherwise,  r  —  p'  and  r  =  p.  Thus  weaken-type  gives 

•  h  u  :  p, 

which  is  our  conclusion. 

Case:  ELIM-SPLIT  Then  3  =  3'U{p}  where  the  premises  of  ELIM-split  are  k  x  3'U  {p',p} 
and  p'  <  p.  By  induction  hypothesis,  there  is  an  r  in  3  U  {p',p}  such  that 

•  b  v  :  r. 

If  r  is  in  s  U  {p},  we  are  done.  Otherwise  r  =  p',  and  WEAKEN-TYPE  gives 

•  v  :  p, 


which  is  our  conclusion. 
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Then  s  =  {k},  so  we  can  choose  r  =  k,  so  our  hypothesis  •  I-  v  :  k  is 

□ 

We  need  to  establish  one  more  lemma,  Lemma  2.70  (Value  Substitution)  on  page  93. 
This  lemma  says  that  substitution  for  expressions  has  a  natural  analogue  that  works  for 
refinement  type  derivations.  We  use  this  lemma  to  prove  soundness  for  the  semantics 
rules  that  use  substitution.  These  rules  are  appl-sem  and  FIX-SEM,  so  we  only  have  to  be 
concerned  with  substituting  values  or  fixed  point  expressions.  It  turns  out  that  we  cannot 
do  much  better  than  this;  in  particular,  we  cannot  substitute  refinement  type  derivations  for 
arbitrary  expressions  into  each  other. 

Since  we  prove  this  lemma  constructively,  the  proof  of  the  lemma  can  be  read  as  an 
algorithm  fordoing  substitution  for  derivations.  For  example,  if  we  perform  the  substitution 

[(fn  y :bool  =>  false  ())/x](x  (x  (true  ()))) 


Case:  self-split 
our  conclusion. 


we  get 

(fn  y :bool  ->  false  ())  ((fn  y :bool  =>  false  ())  (true  ())). 

Lemma  2.70  (Value  Substitution)  on  page  93  will  tell  us  that,  since 

■  F  fn  y:  bool  =>  false  ()  :  tt  — *  ff  A  ff  — *  ff  (2.18) 

and 

[x  :=  tt  -*  ff  A  ff  -*  tt\  F  x  (x  (true  ()))  :  ff,  (2.19) 

we  can  perform  a  corresponding  substitution  on  the  derivations  to  get 

•  F  (fn  y.bool  =>  false  ())  ((fn  y :bool  =>  false  ())  (true  ()))  :  ff.  (2.20) 

The  strategy  for  doing  this  is  simple:  the  constructed  derivation  has  the  same  shape  as  the 
derivation  of  (2.19),  except  wherever  that  derivation  examines  the  type  of  x,  the  constructed 
derivation  incorporates  a  copy  of  the  derivation  of  (2.18).  For  example,  if  we  choose  this 
derivation  for  (2.18): 


y  :  tty-  false  ()  :  ff  y  :  ff  F  false  ()  :  ff 

•  F  f n  y:  bool  =>  false  ()  :  tt  —*  ff  ■  F  fn  y:  bool  =>  false  ()  :  ff  ff 
•  F  f  n  y :  bool  =>  false  () :  tt  — *  ff  \  ff  — ►  ff 

and  this  derivation  for  (2.19)  (using  r  as  an  abbreviation  for  tt  — >  ff  A 


x:rFx:r  r  <  tt  — ►  ff 

x:rFx:r  r  <  ff  — *  ff  x  :  r  h  x  :  tt  — *  ff  x:rF  true  ()  :  tt 

x  \  r  x\  ff  ff  x:rFx  (true  ())  :  ff 

x  :  r  F  x  (x  (true  ())) :  ff 
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then  (where  we  abbreviate  fn  y.bool  =>  (false  ())  as  /  and  replace  all  copies  of  the 
derivation  of  (2.18)  with  . .”) 


...  -h/:r  r  <  tt^ff  ... 

•  h  f  :  r  r  <  ff  —*ff  •  I-  /  :  tt  — *  ff  •  h  true  ()  :  tt 

^f.ff~*ff~  •»-/  (true  ()):ff 

•  h  /  ((fn  y.bool  =>  (false  ()))  (true  ()))  :  ff 

Unlike  Fact  2.6  (ML  Value  Substitution)  on  page  29,  we  cannot  allow  substituting 
arbitrary  expressions  in  a  derivation.  For  instance,  suppose  we  have  a  function  called 
yesno  that  asks  the  user  a  question  to  which  she  can  answer  yes  or  no.  Our  environment 
VR  should  assert  that  yesno  has  the  refinement  type  runit  — >  T iooi.  Assuming  VR  also  has 
appropriate  types  for  or  and  not,  we  can  use  SPLIT-TYPE  to  infer 

VR[x  :=  T i<K>i]  f-  or  (not  x,  x) :  tt 


and  we  can  infer 


VR  h  yesno  ()  :  T \,00i 


but  doing  the  substitution  to  get 


VR  h  or  (not  (yesno  ()),  yesno  ())  :  tt 


(2.21) 


would  lead  to  unsoundness,  since  the  user  could  cause  the  expression  to  evaluate  to  false 
by  saying  “yes”  to  yesno  ()  the  first  time  and  “no”  the  second  time.  Even  if  use  the  fact  that' 
the  semantics  says  the  language  is  completely  functional  and  deterministic  so  the  expression 
yesno  ()  must  either  always  evaluate  to  true  or  always  evaluate  to  false,  the  refinement 
type  system  cannot  infer  (2.21).  Incidentally,  this  example  shows  that  refinement  types  do 
not  rely  upon  determinacy. 

The  problem  is  that  the  type  of  yesno  ()  has  the  split  {tt,ff},  but  yesno  ()  has  neither 
of  the  types  tt  norff.  Thus  Lemma  2.70  (Value  Substitution)  on  page  93  does  not  hold  for 
general  expressions.  Fortunately,  it  does  hold  for  values  and  for  fixed  point  expressions, 
which  is  all  we  need. 


Lemma  2.70  (Value  Substitution)  If  VR  h  e,  :  r1(  where  e\  is  a  value  or  a  closed 
expression  of  the  form  fix  f:t\  =>  fn  x:t2  =>  e",  and  VR(x  :=  r\ J  h  e 2  :  r2,  then 
VR  h  (ei/x]e2  :  r2. 


Proof:  We  prove  this  by  induction  on  the  derivation  of  VR[x  :=  rt]  b  e2  :  r2. 


Case:  AND-INTRO-TYPE 


Then  r2  must  have  the  form  r3  A  r4  where  the  premises  of 


AND-INTRO-TYPE  are 


VR[x  :=  ri]  F  e2  :  r3 
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VR[x  :=  ri]  h  e2  :  r4. 
Applying  the  induction  hypothesis  to  each  of  these  gives 

VR  H  [ej  /x]e2  :  r3 


VR  (-  [ei/x]e2  :  r4. 

Using  AND- intro-TYPE  to  combine  these  last  two  gives 

VR  h  [ei/x]e2  :  r3  A  r4 

which  is  what  we  wanted  to  show. 

Case:  weaken-type  The  premises  of  weaken-type  must  be 

VR[x  :=  ri]  h  e2  :  r3 


(2.22) 


7*3  <  r2. 

Applying  the  induction  hypothesis  to  (2.22)  gives 

VR  1-  [ei/x]e2  :  r3 

and  applying  weaken-type  to  this  and  (2.23)  gives 


VR  h  (ei/x]e?  :  r2 


which  is  the  desired  conclusion. 


(2.23) 


Case:  SPLIT-TYPE  Either  we  rt e  splitting  x  or  some  other  variable. 


SubCase:  Splitting  type  of  x  Then  the  premises  of  split- TYPE  must  be 


r;  X  j 


for  all  r'  in  s  we  have  VR[s  :=  r']  h  e2 :  r2. 


(2.24) 


SubSubCase:  e\  is  a  closed  fixed  point  By  Theorem  2.54  (inferred  Types  Refine)  on 

page  68  and  RX- VALID,  r{  must  refine  an  arrow  type.  Let  r'  be  any  element  of  s;  by 
Fact  2.35  (Splits  of  Arrows  are  Simple)  on  page  51,  r'  =  rx.  WEAKEN-TYPE  gives 

VR  h  e,  :  r' 
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and  then  our  induction  hypothesis  gives  VR  b  [ej /x\e2  :  r2)  which  is  our  conclusion. 

SubSubCase:  e\  is  a  value  Then  Theorem  2.69  (Splitting  Value  Types)  on  page  89  tells 

us  that  there  is  an  r'  in  a  such  that  •  b  e\  :  r'.  By  Fact  2.47  (Non-free  Variables  are  Ignored) 
on  page  63,  this  implies  VR  b  e\  :  r'.  Our  induction  hypothesis  applied  to  this  and  (2.24) 
then  gives  VR  b  [ei/x]e2  :  r2,  which  is  our  conclusion. 

SubCase:  Not  splitting  type  of  x  Then  VR  has  the  form  VR'[y  :=  k\,  where  we  are 
splitting  the  type  of  y.  SPLIT-TYPE  gives 

k  x  a 


which  is  our  conclusion. 

Case:  ABS-TYPE  Then  e2  must  have  the  form  f n  y:t  =>  e'.  We  take  cases  on  whether 
x  =  y. 

SubCase:  x  =  y  Then  [ei/x]e2  =  [ej/xjfn  x:t  =>  e'  =  fn  x:t  =>  e'  =  e2,  so  the 
conclusion  is  one  of  the  hypotheses. 
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SubCase:  y  ^  x  From  ABS-TYPE  we  know  that  r2  must  have  the  form  r3  — >  r4.  For  some 
t,  the  premises  of  abs-type  must  be 


VR[x  :=  r\,y  :  =  r3)  (-  e  :  r4 


(2.25) 


r3  C  t 


(2.26) 


[ei/x]e2  =  fn  y:t  =>  [ej/xje'. 
Applying  the  induction  hypothesis  to  (2.25)  gives 

VR[y  :=  r3]  h  [e\/z\e  :  r4 

and  applying  ABS-TYPE  to  this  and  (2.26)  gives 


VRh  fn  j/:l  =>  [e3 /x]e' :r3— >r4 


which  is  our  conclusion. 


Case:  APPL-TYPE  The  conclusion  of  APPL-TYPE  tells  us  that  e2  has  the  form  e3  e4  and 
the  premises  of  appl-type  have  the  form 

VR[x  :=  ri]  t-  e3  :  r3  — »r2 

and 

VR[x  :=  ri]  h  e4  :  r3. 

Applying  the  induction  hypothesis  to  each  of  these  gives 

VR  h  [ei/x]e3  :  r3  -»r2 


VR  h  [ei/xje4  :  r3. 

Using  appl-type  on  the  last  two  gives 

VR  I-  ([ei/x]e3)  ([ei/x]e4)  :  r2, 

and  since  ([ei/xje3)  ([e!/x]e4)  =  [ej/x](e3  e4),  this  is  our  conclusion. 

Case:  CONSTR-TYPE  Then  e2  has  the  form  c  e'  and  r2  has  the  form  rc.  The  premises  of 


CONSTR-TYPE  must  be 


def 

c  :  r  m  rt 


VR[x  :=  rj]  F  e' :  r. 
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The  induction  hypothesis  gives 

VR  H  [ei/x]e' :  r 

and  then  constr-type  gives 

VR  \~  c  [et/x]e' :  rc. 

[e\ /x](c  e'),  this  is  our  conclusion. 

Then  e2  has  the  form  case  e'0  of  c\  =>  e\  I  ...  I  c„=>  e’n  end  :t 
and  the  premises  of  case-type  are 

VR[x  :=  ri]  t-  e'0  :  rc, 

r2  C  t, 

for  all  *  in  1 . . .  n  and  all  k,  whenever 


Ci  d?f  k  «— ►  rc  we  have 

VR[x  :=  n]  F  ej :  k— >r2, 

(2.27) 

and 

rtom(VR[x  :=  n])  h  e2  ::  t. 

(2.28) 

Our  induction  hypothesis  gives 

VR  H  [et/x]eo  :  rc. 

(2.29) 

Suppose 

def  . 

Ci  :  k  c— »  rc. 

(2.30). 

Then  by  (2.27),  we  have 

VR[x  :=  ri]  h  e-  :  k  — >r2. 

and  our  induction  hypothesis  gives 

VR  h  [ei/x]ej :  k  -+r2. 

(2.31) 

Theorem  2.54  (Inferred  Types  Refine)  on  page  68  and  VR  r  e\  :  gives 

rtom(VR)  h  e\  ::  rtom(ri). 

Fact  2.6  (ML  Value  Substitution)  on  page  29  applied  to  this  and  (2.28)  gives 

rtom(VR)  h  [ei/x]e2  ::  t  (2.32) 

Now  we  can  use  CASE-TYPE  on  (2.29),  r2  C  t,  (2.30)  implies  (2.31),  and  (2.32)  to  get 
VR  F  (case  [ej/x]eo  of  ci  =>  [ej /x]e',  I  ...  I  Cn  =*>  [ e\/x]e'n  end:f  :)r2 
Since 

case  {e\lx\e'Q  of  cj  =>  [ei/xje'|  I  ...  I  c„  =>  [ej/x]eJ x  end :t  = 
[ej/x](case  ej  of  cj  =>  e\  I  ...  I  c„  ->  e'n  end :t), 


Since  c  [ej /x \e'  = 
Case:  case-type 
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this  is  our  conclusion. 

Case:  TUPLE-TYPE  Then  e2  has  the  form  (ei ,  ...»  en)  and r2  has  the  form  t\  * ...  *  r'n 
and  the  premises  of  tuple-type  must  be 

for  t  in  1 ... n  we  have  VR[x  :=  ri]  h  ej :  r[. 

By  induction  hypothesis, 

for  *  in  1 . . .  n  we  have  VR  f-  [ei  /xjej :  r{. 

Then  TUPLE-TYPE  gives 

VR  h  ([ei/*]e', ,  ...,  [ei  /  x]e'n)  :  r[  *  . . .  *  r'n. 

Since  ([ei/x]e,,  ...»  [ei/x]eJJ  =  [ei/x](e\ ,  ...,  e'n)  and  r2  =  t\  *  . . .  *  r'n,  this  is  our 
conclusion. 

Case:  ELT-TYPE  Then  e2  has  the  form  elt _m_n  e'  and  the  premise  of  ELT-TYPE  must  be 

VR[x  :=  rj]  h  e' :  *  . . .  *  r'n 

where  r2  =  r'm.  Our  induction  hypothesis  gives 

VR  I-  (ei/x]e' :  r\  *  r'n 

and  ELT-TYPE  then  gives 

VR  h  elt _m_n  [e\/x]e' :  r'm. 

Since  r2  =  r'm  and  elt_m_n  [ej/x je'  =  [ej /x]elt _m_n  e',  this  is  our  conclusion. 

Case:  FIX-TYPE  Thus  e2  has  the  form  fix  =>  fn  y:t\  =>  e'.  If  x  =  y  or 

x  =  /,  then  our  conclusion  is  trivial  because  [ei/x]e2  =  e2.  Otherwise,  the  premises  of 
FIX-TYPE  are 

r2  C  t\  (2.33) 

and 

VR[/  :=  r2]  h  fn  x:t\  =>  e' :  r2. 

Our  induction  hypothesis  gives 

VR[/  :=  r2]  I-  [ei/x]fn  y:t\  =>  e' :  r2. 

Since  x  ^y,  this  is 

VR [/  :=  r2]  h  fn  =>  [ej /x]e' :  r2. 

Applying  FIX-TYPE  to  this  and  (2.33)  gives 

VR  I- f  ix  f:t\— *t2  ->  fn  y:t\  =>  [ei/x]e' :  r2. 


2.8.  SIMPLE  SOUNDNESS  PROOF 
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Since  x  ^  y  and  x  /,  this  is  our  conclusion.  □ 

Now  that  we  have  established  all  of  the  lemmas  we  need  for  the  soundness  proof,  we 
are  in  a  position  to  show  that  this  version  of  the  system  is  sound.  So  we  come  to  the 
question:  What  does  it  mean  for  the  refinement  type  system  to  be  sound?  It  turns  out 
that  until  we  introduce  explicit  type  declarations  or  references,  all  expressions  that  have  an 
ML  type  will  also  have  a  refinement  type.  Thus  the  notion  of  ML  type  soundness  used  in 
Fact  2.3  (ML  Type  Soundness)  on  page  27  is  trivially  true  for  refinement  types,  so  it  is  not 
interesting  here.  The  most  interesting  thing  we  can  claim  at  this  point  is  that  if  we  evaluate 
an  expression,  the  value  has  the  same  type  as  the  expression: 

Theorem  2.71  (Refinement  Type  Soundness)  Ife  =>  v  and  •  b  e  :  r,  then  ■  h  v  :  r. 

We  could  prove  this  by  induction  on  the  derivation  of  e  =>  v.  At  each  step  in  the  proof, 
there  would  be  three  inference  rules  that  could  have  been  used  to  derive  •  h  e  :  r.  They 
are  WEAKEN-TYPE,  AND-INTRO-TYPE,  and  one  inference  rule  that  deals  specifically  with  the 
outermost  syntax  of  e.  (SPLIT-TYPE  cannot  happen  here  because  it  requires  a  nonempty 
variable  environment.)  For  example,  if  e  has  the  form  ex  e2,  the  last  inference  rule  in 
the  derivation  of  e  =>  v  must  be  APPL-SEM  and  the  possible  inference  rules  at  the  root 
of  •  h  e,  e2  :  r  are  WEAKEN-TYPE,  and-intro-type,  and  appl-TYPE.  The  step  of  the 
proof  dealing  with  APPL-SEM  would  have  to  have  another  induction  on  the  derivation  of 
•  l-e!  e2:r  to  strip  off  the  outermost  uses  of  WEAKEN-TYPE  and  and-intro-TYPE,  before 
we  could  use  the  outer  induction  to  make  more  progress  on  the  evaluation  trace.  Since  each 
step  of  the  proof  would  have  to  have  this  nested  induction,  the  proof  would  be  too  large  to 
manage. 

It  would  not  work  to  prove  the  theorem  by  induction  on  the  type  derivation.  The 
substitution  in  the  APPL-SEM  rule  can  make  the  expression  larger,  and  therefore  it  can  make 
the  type  derivation  larger.  Thus  induction  on  the  type  derivation  is  invalid. 

There  are  two  kinds  of  ways  to  make  progress  in  the  above  procedure:  We  can  use 
AND-INTRO-TYPE  or  WEAKEN-TYPE  to  make  the  type  derivation  smaller  while  leaving  the 
evaluation  derivation  constant,  or  we  can  use  any  of  the  semantics  rules  to  make  the 
evaluation  derivation  smaller  while  possibly  making  the  type  derivation  larger.  All  of 
these  possibilities  make  the  ordered  pair  (evaluation  trace,  type  derivation)  lexicograph¬ 
ically  smaller.  Since  any  decreasing  chain  in  the  lexicographic  ordering  on  the  pair  is 
finite,  proof  by  induction  on  the  pair  is  a  valid  induction  principle,  and  this  is  the  induction 
principle  we  shall  use. 

The  base  cases  of  this  induction  are  the  minimal  elements  in  the  lexicographic  ordering. 
These  consist  of  a  use  of  a  semantics  rule  that  requires  no  premise  paired  with  a  use  of  a 
refinement  type  rule  other  than  WEAKEN-TYPE,  and-intro-TYPE,  or  split-type.  It  turns 
out  that  there  are  three  base  cases: 

(abs-sem,  abs-type) 

(TUPLE-SEM,  tuple-type)  for  a  tuple  of  zero  elements 
(fix-sem,  fix-type') 
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Proof:  The  proof  is  by  induction  on  the  pair  (derivation  of  e  =>  v,  derivation  of  •  h  e  :  r). 
We  shall  label  each  case  with  the  with  an  indication  of  the  pairs  to  which  it  applies.  The 
label  will  either  be  “any”  if  the  case  applies  to  pairs  with  any  value  for  that  component, 
or  the  name  of  an  inference  rule  if  the  case  applies  only  to  pairs  where  that  component  of 
the  pair  has  that  inference  rule  at  the  root  of  the  derivation.  The  most  interesting  case  is 
(aPPL-SEM,  APPL-TYPE),  since  that  case  uses  the  machinery  developed  earlier  in  this  chapter. 
There  is  an  example  after  this  proof  on  page  103. 

Case:  (any,  and- INTRO-TYPE)  Then  r  has  the  form  n  A  r2.  The  premises  of  AND-INTRO- 

TYPE  must  be  •  l-  e  :  t*i  and  ■  h  e  :  r2.  Applying  the  induction  hypotheses  to  each  of  these 
gives  •  h  77 :  ri  and  •  h  v  :  r2.  Combining  these  with  AND-ENTRO-TYPE  gives 

•  h  t;  :  7*i  A  r2 

which  is  our  conclusion. 

Case:  (any ,  weaken-type)  The  premises  of  weaken-type  must  be 

•  he:/ 
and 

r'  <  r. 

Applying  the  induction  hypothesis  to  (2.34)  gives 

-1—77 :  r' . 


(2.34) 

(2.35) 


Applying  WEAKEN-TYPE  to  this  and  (2.35)  gives 

•  h  77  :  r, 

which  is  our  conclusion. 

Case:  (any,  split-type)  This  case  is  unreachable  because  split-type  assumes  the  envi¬ 
ronment  is  nonempty,  but  the  hypothesis  of  this  theorem  assumes  it  is  empty. 

Case:  (abs-SEM,  abs-TYPE)  By  ABS-SEM,  77  =  e.  Thus  our  hypothesis  •  I-  e  :  r  is  our 
conclusion. 

Case:  (appl-SEM,  APPL-TYPE)  Then  e  must  have  the  form  e\  e2  and  the  premises  of 
appl-sem  must  be 


e\  =>  fn  x:t  =>  e 3 

(2.36) 

e2  =>  v' 

(2.37) 

[17'/ aj]e3  =»  77 

(2.38) 

2.8.  SIMPLE  SOUNDNESS  PROOF 
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and  the  premises  of  appl-type  must  be 

•  h  e\  :  r'  — >  r  (2.39) 

•  h  e2  :  r'.  (2.40) 

Applying  the  induction  hypothesis  to  (2.36)  and  (2.39)  gives 

•  h  f  n  x:t  ->  ej  :  r'  —*r 
and  Lemma  2.68  (Subtype  Irrelevancy)  on  page  88  tells  us 

•  H-  f n  x :  t  =>  ej  :  r'  — * r. 

The  last  inference  of  this  must  be  abs-TYPE  with  the  premise 

x  :  /  h  e-}  :  r.  (2-41) 

Applying  the  induction  hypothesis  to  (2.37)  and  (2.40)  gives 

and  using  Lemma  2.70  (Value  Substitution)  on  page  93  to  substitute  this  into  (2.41)  gives 

•  1-  [v  /x\e-i  :  r. 

Applying  the  induction  hypothesis  to  this  and  (2.38)  gives 

•  h  t j  :  t 


which  is  our  conclusion. 


Case:  (CONSTR-SEM,  CONSTR-type)  Then  e  must  have  the  form  c  e'  and  r  must  have  the 

form  rc  and  v  must  have  the  form  c  v'  where  the  premise  of  CONSTR-SEM  is  e'  =>  v'  and 
the  premises  of  constr-type  are 


del  • 

c  :  k  >  rc 


Our  induction  hypothesis  gives 


and  then  constr-type  gives 


•  I -  e' :  k. 


•  h  v':k 


he  v1 :  rc, 


which  is  our  conclusion. 

Case:  (case-sem,  case-type)  The  e  must  have  the  form 


case  eo  of  Ci  =>  e\  j  ...  I  Cn  =>  en  end : u. 
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The  premises  of  case-sem  must  be 

for  some  i  we  have  eo  =>  Vi 
and 

ei  Vi  =>  v 

and  the  premises  of  case-type  must  include 

•  b  eo  :  re, 

r  [I «, 
and 

for  all  i  in  1 . . .  n  and  all  k,  if 

def  . 

d  :  k^rc  (2 .42) 

then 

•  b  ei :  k  — » r 

Using  the  induction  hypothesis  on  eo  gives 

•  b  Ci  Vi  :  re. 

Lemma  2.68  (Subtype  Irrelevancy)  on  page  88  then  gives 

•  H- a  Vi:  rc. 

The  last  inference  of  this  must  be  constr-type  with  the  premises 

def  . 

Ci  :  k  5 — *  rc 

and 

•  h  V{ :  k. 

By  (2.42),  we  have 

•  h  ei  :  k  — ►  r. 

Using  APPL-TYPE  on  these  gives  •  h  e<  Vi :  r.  Using  the  induction  hypothesis  on  this  gives 
which  is  our  conclusion. 

Then  e  has  the  form  (ei ,  . . . ,  en)  and  r  has  the  form 
. vn).  The  premises  of  tuple-sem  are 

6  i . . .  n  we  have  ej 

and  the  premises  of  TUPLE-TYPE  are 


Case:  (tuple-sem, tuple-type) 

*  . . .  *  rn  and  v  has  the  form  («i 

for  i 


for  i  €  1 ...  n  we  have  •  H  ei :  ri. 


2.8.  SIMPLE  SOUNDNESS  PROOF 
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The  induction  hypothesis  gives 

for  i  €  1 ...  n  we  have  •  :  r<, 

and  then  tuple-type  gives 

•(-(«!,  ...,  vn)  :  ri  * ...  *r„, 

which  is  our  conclusion. 

Case:  (elt-SEM,ELT-TYPE)  Then  e  must  have  the  form  elt _m_n  e'.  The  premise  of 
ELT-SEM  must  be 

e  ^  (Uj  ,  ...»  Un) 

where  v  =  vm,  and  the  premise  of  ELT-TYPE  must  be 

•  f-  e' :  r(  * . . .  *  r„ 

where  r  =  rm.  Our  induction  hypothesis  gives 

•  I-  («!,  ...»  t :  pi  *  ...  *rn. 

By  Lemma  2.68  (Subtype  Irrelevancy)  on  page  88,  this  implies 

...»  vn)  :  r\  * ...  *rn. 

The  last  inference  of  this  must  be  TUPLE-TYPE,  and  one  of  the  premises  must  be 

which  is  our  conclusion. 

Case:  (FIX-SEM, FIX-TYPE)  The  e  has  the  form  fix  f:t'  =>  fn  x:t"  ->  e'.  By  FIX- 

TYPE,  t'  has  the  form  t\  — » t2  and  t"  =  t\.  The  premises  of  FIX-TYPE  must  be  r  c  t\  — >  t2 
and 

[/  :=  r]  H  f n  x:t\  =>  e'  :  r. 

Using  Lemma  2.70  (Value  Substitution)  on  page  93  on  this  and 

■  h  e  :t 


gives 

•  H  [e//](fn  x:t\  =>  e'):r  (2-43) 

By  FIX-SEM,  v  is  (e//](fn  x:t\  =>  e'),  so  (2.43)  is  our  conclusion.  □ 

The  role  of  split-type  in  these  theorems  is  interesting,  since  it  can  appear  at  a  non¬ 
root  position  in  the  type  derivation  in  the  hypothesis  of  Theorem  2.71  (Refinement  Type 
Soundness)  on  page  99,  but  none  of  the  cases  in  that  proof  deal  with  that  rule.  The 
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resolution  to  this  paradox  is  that  the  proof  of  Lemma  2.70  (Value  Substitution)  on  page  93 
never  constructs  a  derivation  with  SPLIT-TYPE  at  the  root. 

This  can  be  most  easily  understood  by  walking  through  the  reasoning  in  the  appl-sem 
case  of  Theorem  2.71  (Refinement  Type  Soundness)  on  page  99  for  a  carefully  chosen 
example.  For  the  purposes  of  this  example,  let  or  stand  for 

fn  pair:  bool  *  bool  => 
case  #1,2  pair  of 

true  =>  fn  _:tunit  =>  true  () 

I  false  =>  fn  tunit  =>  #2,2  pair 
end :  bool 


and  not  stand  for 


fn  b :  bool  => 
case  b  of 

true  =>  fn  _ :  tunit  =>  false  () 

I  false  =>  fn  tunit  =>  true  () 
end:  bool . 

We  shall  choose  e  =  (fn  x:bool  =>  or  ( not  x,  x))  (true  ())  and  r  =  tt,  so  we  need 
v  =  true  ().  We  will  abbreviate  or  ( not  x,  x)  as  e'  and  true  ()  as  tr  when  necessary 
to  get  the  following  derivations  to  fit  on  a  page.  The  derivation  of  e  =>  v  is 

_  ()=►()  ••• 

fn  x:bool  =>  e'  =r>  fn  x:bool  =>  e1  tr  =>  tr  or  ( not  tr,  tr)  =>  tr 

(fn  x:bool  =>  e')  tr  =>  tr 


and  a  derivation  of  •  t-  e  :  r  is 


x:  ff  e' :  tt  x  :  tt  h  e' :  tt  T  t,00t  x  {tt,ff} 

x  :  T i00i  h  e'  :  tt  •  h  true  ()  :  tt  tt  <  T &«„/ 

•  h  fn  x:bool  =>  e' :  T  fai  —>  tt  •  h  true  () :  T j*,/ 

•  h  (fn  x:  bool  ~>  e')  (true  ())  :  tt. 

Notice  the  use  of  SPLIT-TYPE  in  this;  it  is  the  rule  with  the  premise  T iool  x  {tt,ff}. 
This  example  would  be  less  than  ideal  if  we  had  no  size  constraint  because  it  is  also 
possible  to  derive  Our  conclusion  without  ever  using  SPLIT-TYPE;  we  could  sir/ ply  start 
with  x  :  tt  he':  tt,  use  ABS-TYPE  to  infer  •  h  fn  x:  bool  =>  e1  :  tt  — >  tt,  and  then  use 
APPL-TYPE  and  •  F  true  ()  :  tt  to  infer  our  conclusion.  For  a  more  serious  but  larger 
example,  we  could  replace  the  true  ()  by  an  expression  with  the  principal  type  T  thus 
requiring  the  use  of  split-type  to  reach  the  strongest  conclusion. 


2.9.  FINITE  REFINEMENTS,  PRINCIPALITY 


105 


However,  let  us  instead  show  how  the  theorem  manipulates  the  example  as  it  stands. 
First  the  theorem  trivially  applies  the  induction  hypothesis  to 

fn  xibool  =>  (or  ( not  x,  x))  =>  in  xibool  =>  (or  (not  x,  x)) 


and 


to  get 


•  h  in  xibool  =>  (or  (not  x,  x))  :  T it 


•  h  fn  xibool  =>  (or  (not  x,  x)) :  T M  — >  tt. 
Then  it  uses  Lemma  2.68  (Subtype  Irrelevancy)  on  page  88  on  this  to  get 

•H-fn  xibool  =>  (or  (not  x,  x))  :  T ioo/  — » tt , 

Since  the  last  inference  of  this  must  be  APPL-TYPE,  we  must  have 


[x  :=  Tj*,/]  t-  (or  (not  x,  x)) :  tt.  (2.44) 

Another  trivial  use  of  the  induction  hypothesis  uses  true  ()  =>  true  ()  and  •  h  true  ()  : 
T  too/  to  infer 

•  h  true  () :  Ttoo/.  (2-45) 

Then  we  eliminate  the  use  of  SPLIT-TYPE  by  substituting  (2.45)  into  (2.44)  to  get 

•  H  or  (not  (true  ()),  (true  ()))  :  tt. 

Using  the  induction  hypothesis  on  this  and  or  ( not  (true  ()),  (true  ()))  =>  true  () 
yields  •  F  true  () :  tt,  which  is  our  conclusion. 

This  concludes  the  soundness  proof  of  the  monomorphic  version  of  refinement  types. 
This  proof  has  roughly  the  same  shape  as  the  proofs  of  soundness  for  polymorphic  refine¬ 
ment  types  and  refinement  types  with  declarations  and  references. 


2.9  Finite  Refinements,  Principality 

Now  we  shall  give  several  lemmas  leading  up  to  the  proof  that,  roughly  speaking,  each  ML 
type  has  only  finitely  many  distinct  refinements. 

This  proof  below  is  slightly  more  complex  than  necessary.  A  simpler  proof  would  show 
by  induction  on  the  ML  type  that  each  ML  type  has  finitely  many  distinct  refinements.  In 
this  proof,  the  interesting  induction  case  would  happen  when  the  ML  type  has  the  form 
t  — >  u;  if  t  has  n  distinct  refinements  and  u  has  m  distinct  refinements,  then  there  are  at  most 
n  *m  distinct  refinements  of  the  form  r  — >  k  where  r  d  t  and  k  C  u.  Every  refinement 
of  t  — ►  u  is  equivalent  to  an  intersection  of  some  subset  of  these,  so  there  are  at  most  2"*m 
refinements  of  t  —*  u. 
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The  problem  with  this  simple  approach  is  that  it  overestimates  the  number  of  refinements 
of  many  ML  types.  For  example,  the  refinement  types  T  ^  — >  tt  A  tt  — *  tt  and  T  — 1 >  tt 
are  equivalent,  but  they  are  both  counted  in  the  enumeration  implied  in  the  argument  above. 
The  implementation  sometimes  has  to  enumerate  the  refinements  of  an  ML  type,  so  it  is 
worthwhile  to  explore  a  more  conservative  enumeration  in  the  finiteness  proof. 

The  strategy  behind  the  proof  below  is  to  interpret  a  refinement  of  t  — >  u  as  a  monotone 
function  from  equivalence  classes  of  t  to  equivalence  classes  of  u.  Two  refinement  types 
are  equivalent  if  and  only  if  their  interpretations  are  equal,  and  we  can  enumerate  without 
repetition  all  refinements  of  a  functional  ML  type  by  enumerating  all  monotone  functions 
with  an  appropriate  domain  and  codomain,  as  we  shali  describe  below. 

For  any  r  refining  a  functional  ML  type,  we  will  define  the  interpretation  7(r)  of  r  in 
terms  of  a  simpler  function  i(r)  that  maps  refinement  types  to  refinement  types  instead  of 
equivalence  classes  to  equivalence  classes. 

There  is  a  natural  way  to  read  the  interpretation  t(r):  If  /  has  the  type  r  and  x  has 
the  type  k,  then  the  best  type  we  can  infer  for  f  x  is  i(r)(k).  Our  plan  is  to  set  up  some 
machinery  that  allows  us  to  define  i  in  terms  of  the  subtype  relation,  and  then  to  show  that 
two  types  k  and  k!  are  equivalent  if  and  only  if  i(k)  and  i(k')  are  suitably  similar.  Then  we 
will  define  /  to  be  t  lifted  in  a  natural  way  to  operate  on  equivalence  classes  of  refinement 
types.  It  will  turn  out  that  any  types  k  and  k'  are  equivalent  if  and  only  if  /(fc)  and  I(k') 
are  equal.  Then  we  finish  the  proof  by  showing  that  there  are  only  finitely  many  distinct 
values  for  /(&). 

To  make  the  proof  more  regular,  we  will  use  the  symbol  ns  as  the  result  of  i{r)(k) 
when  the  corresponding  expression  would  have  no  type.  For  example,  i(tt  =  ns. 

Adding  ns  requires  us  to  introduce  notation  for  metavariables  that  can  be  either  a  refinement 
type  or  ns.  We  will  write  these  metavariables  as  rl,  kl  or  p?  and  call  the  values  of  these 
metavariables  generalized  refinement  types.  Comparing  them  is  straightforward: 

Definition  2.72  We  define  the  binary  relation  X  on  generalized  refinement  types  by  the 
following  cases: 

r  <k  if  and  only  ifr<k 
r  X  ns  always 
ns  X  k  never 
ns  X  ns. 


We  can  base  a  natural  notion  of  equivalence  on  X: 

Definition  2.73  We  say  r?  «  kl  if  rl  X  kl  and  kl  X  rl. 

We  could  get  the  same  effect  by  defining  rl  ~  kl  to  mean  that  either  rl  =  kl  or  rl  =  kl  = 
ns. 

We  can  also  define  intersection  on  generalized  refinement  types: 
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Definition  2.74  We  define  the  binary  operation  A  mapping  pairs  of  generalized  refinement 
types  to  generalized  refinement  types  by  the  equations: 

r  A  k  —  r  A  k 
r  A  ns  =  ns  A  r  =  r 
ns  A  ns  =  ns. 


The  A  operation  inherits  commutativity,  associativity,  and  idempotence  from  A. 

The  big  advantage  of  A  over  A  is  that  A  has  an  identity,  specifically  ns.  Thus  we  can 
define  A  to  work  on  a  finite  set  of  refinement  types  even  if  the  set  is  empty: 

Definition  2.75  If  a  is  a  finite  set  of  refinement  types,  then  As  is  the  following  generalized 
refinement  type: 

If  a  is  empty,  then  As  =  ns. 

If  s  =  ,rn},  then  As  =  n  A  ...  A  rn. 

We  shall  continue  to  use  3  as  a  finite  set  of  refinement  types  for  the  rest  of  this  section. 

This  definition  is  slightly  ambiguous,  since  the  order  of  the  elements  in  a  set  is  not 
determined  and  A  is  only  commutative  if  we  ignore  the  difference  between  equivalent 
refinement  types  that  are  not  equal.  For  example,  A{tt,ff}  could  be  tt  A  ff  as  well  as 
ff  A  it.  This  ambiguity  makes  no  difference  to  the  reasoning  below,  and  we  shall  ignore  it. 

When  all  refinement  types  in  3  refine  the  same  ML  type  t,  the  generalized  refinement 
type  A 3  either  refines  t  or  is  ns.  We  extend  the  notion  of  refinement  to  include  sets  of 
refinement  types  and  generalized  refinement  types,  so  we  can  simply  say  that  if  3  c  t,  then 
Aa  C  t.  In  this  extension  of  the  meaning  of  C,  both  the  empty  set  {}  and  ns  both  refine  all 
ML  types. 

The  A  operator  has  several  properties  that  follow  from  analogous  properties  of  A, 
commutativity  and  associativity  of  A,  and  trivial  induction  arguments: 

Fact  2.76  (A  Elim  Sub)  // a  D  s'  and  act  then 

Aa  ■<  A  s'. 

Fact  2.77  (A  Intro  Sub)  If  s\,  a2,  and  a3  all  refine  t  and 

Aai  ■<  A 32 


and 


Aai  ^  Aa3 


then 


Aai  ^  A(a2  U  a3). 
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Fact  2.78  (TYansitivity  of  x)  Ifrl  x  kl  and  kl  x  p?  then  r!  x  p?. 


Now  we  have  enough  machinery  to  define  i(r )  and  prove  some  simple  properties  of  it: 

Definition  2.79  Suppose  kl  □  t  — >  t'  and  r  C  t.  Ifkl  has  the  form  k\  — *  k[  A . . .  A  kn  — >  k'n, 
we  define 

i(A:?)(r)  =  A{fc'  |  j  is  between  1  and  n  and  r  <  kj}. 

Otherwise  kl  =  ns  and  we  define  i(kl)(r )  =  ns. 

For  example,  if 

k  =  tt  — *  T  i,00i  A  T  boot  —*  ff  A  ff  — >  tt 

then 

i(k)(tt)  =  Tj00;  A  ff  =  ff 
*(*)(#)  =  ff  A  tt  =  ±ioal 
i(A=)(T4oo/)  =  ff 

=  T bool  ^  ff  A  tt  —  -i-400j. 

In  this  example,  as  r  gets  larger,  i(A:)(r)  also  gets  larger.  This  property  is  true  in  general. 

Lemma  2.80  ( i  Monotone  in  Second  Argument)  Ifr  C  t  and  kl  \zt-*t'  and 

r  <  r' 


then 

i(kl)(r)  X  i(fc?)(r'). 


Proof:  If  As?  =  ns,  thenourresultfollowsdirectlyfromthedefinitionsoftandx.  Otherwise 

kl  has  the  form  k\  — *  k[  A  . . .  A  kn  — *  k'n.  As  in  the  definition  of  i,  let 

a  =  {k'j  |  j  between  1  and  n  and  r  <  kj} 


and 


s'  =  {kj  |  j  between  1  and  n  and  r'  <  kj}. 


Since  r  <  r  and  <  is  transitive,  we  have  s  D  s'.  Since  k  C  t  — >  t',  all  of  the  k}' s  must 
refine  t',  so  s  C  t'.  Thus  we  can  use  Fact  2.76  (A  Elim  Sub)  on  page  107  to  get 


As  X  A  s'. 


According  to  the  definition  of  i,  this  is  our  conclusion.  □ 

It  is  also  true  that  as  kl  gets  larger,  i(kl)(r)  gets  larger,  but  the  proof  is  somewhat  more 
involved: 


2.9.  FINITE  REFINEMENTS,  PRINCIPALITY 


109 


Lemma  2.81  (*  Monotone  in  First  Argument)  Ifr  c  t  and  kl  C  t  -» t'  and 

kl  X  pi 


then 

i(k?)(r)  X  i(p?)(r). 


Proof:  By  induction  on  the  derivation  of  kl  X  p?. 

Case:  p?  =  ns  Then  i(p?)(r)  =  ns,  and  our  result  follows  from  the  definition  of  x. 
Case:  kl  —  ns  Then  p?  =  ns,  so  the  previous  case  holds. 

Case:  SELF-SUB  Trivial. 

Case:  and-ELIM-r-sub  Since  kl  (I  t  — >  t'  we  know  that  kl  has  the  form  k\—*  k\  A  ...  A 
kq  k'q.  The  shape  of  AND-ELIM-R-SUB  tells  us  there  is  some  n  less  than  q  such  that 

p?  =  — >  k[  A  . , .  A  kn  -»  k'n. 


Let 

and 


s  =  {k'j  |  j  between  1  and  q  and  r  < 
s'  =  {k'j  |  j  between  1  and  n  and  r  <  kih 


Since  n  <  q  we  have  s  D  s'.  Thus  Fact  2.76  (A  Elim  Sub)  on  page  107  gives 


A  s  X  A  s', 


and  by  definition  of  i,  this  is  our  conclusion. 

Case:  AND-ELIM-L-SUB  Similar. 

Case:  AND-INTRO-SUB  Then  pi  has  the  form  p\  A  pi ,  where  the  premises  of  and-intro- 
SUB  are 

kl  <  pi 

and 

kl  <  p2- 

Applying  our  induction  hypothesis  to  these  gives 


i(kl)(r)  X  i(pi  )(r ) 
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and 


*(A:?)(r)  X  *(P2 )(**)• 

Since  p?  =  px  A  pz,  the  definition  of  *  tells  us  that  t(/>?)(r)  =  i(p\){r)  A  i(p2)(r).  Thus 
Fact  2.77  (A  Intro  Sub)  on  page  107  gives  i(kl)(r)  X  i(p?)(r),  which  is  our  conclusion. 


Case:  trans-sub 


Then  the  premises  of  trans-sub  must  be 


fc?  <r' 


and 


r'  <  p?. 


Applying  the  induction  hypotheses  to  these  gives 


i(fc?)(r)  X  i(r')(r) 


and 

t(r')(r)  X  t(p?)(r). 

Using  Fact  2.78  (Transitivity  of  X)  on  page  108  on  these  gives  our  conclusion. 


Case:  arrow-sub 


Then  fc?  has  the  form  k\  — >  k[  and  p?  has  the  form  p\  — ►  p\  and  the 


premises  of  arrow-sub  are 


Pi  < 


and 

K  <p\. 

If  *(p?)(r)  =  ns  then  our  conclusion  follows  immediately,  so  instead  suppose  that  i(p?)(r) 
is  a  refinement  type.  From  the  definition  of  i  we  must  have  r  <  p\  and  i(p?)(r)  =  p\ . 
TRANS-SUB  and  P\  <  kx  give  r  <  fci,  and  the  definition  of  i  gives  t(fc?)(r)  =  fcj.  Thus 
fcj  <  p\  is  our  conclusion. 


Case:  arrow- and-elim-sub 


Then  fc?  must  have  the  form  k\ 


k\  Ak\  -+k!,  and  p?  must 


have  the  form  fci  —*(k{  A  fc £).  If  i(p?)(r)  =  ns  then  the  definition  of  X  gives  our  conclusion 
immediately.  Otherwise  the  definition  of  i  gives  r  <  k\  and 


t(fc?)(r)  =  fcj  A  fcj 


and 

»(p?)(r)  =  fc;  A  fc£. 

Before  we  use  self-sub  to  get  our  result  we  must  find  a  u'  such  that  fc{  A  fc£  C  u'.  The 
premise  of  arrow-and-elim-sub  is 


kx  ->(fc;  A  fc^)  c  t. 
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This  can  only  be  derived  by  using  arrow-ref,  so  t  must  have  the  form  u—*u'  and  the 
premises  of  arrow-ref  must  be 

i|Cu 

and 

a  ^  c  u'. 

The  latter  and  SELF-SUB  give  our  conclusion. 


Case:  RCON-SUB,  RCON-AND-ELIM-SUB,  TUPLE-SUB,  TUPLE- AND-ELIM-SUB 

None  of  these  cases  can  happen  because  we  assume  that  kl  and  p?  refine  a  functional  ML 
type.  □ 

This  has  a  simple  corollary: 

Corollary  2.82  (Bound  on  Argument  to  *  Gives  Bound  on  i) 

Ifk<  r—>p  then  *(fc)(r)  <  p. 

Proof:  The  definition  of  i  gives  i(r  — *p)(r)  =  p.  By  Lemma  2.81  (i  Monotone  in  First 
Argument)  on  page  109,  »(fc)(r)  <  i(r  -*p)(r),  and  rewriting  i(r  -*p)(r)  to  p  gives  our 
result.  □ 

We  will  call  rx , . . . ,  r„  the  components  of  the  refinement  type  rx  A . . .  A  rn. 

From  the  definition  of  i,  it  is  clear  that  if  r  — ►  r'  is  one  of  the  components  of  k,  then 
i(fc)(r)  <  t'.  The  converse  of  this  is  false;  for  example,  if  k  —  tt  -» ff  A  tt  ->  tt  and  r  =  tt„ 
then  i{k)(r)  =  ff  A  tt  but  tt  —>(ff  A  tt)  is  not  one  of  the  components  of  k.  However,  we 
do  have  k  <  tt  —>(ff  A  tt),  and  this  sort  of  assertion  is  true  in  general. 

Lemma  2.83  (*  Gives  an  Upper  Bound)  If  k?  and  r  c  tx  and 

z(fc?)(r)  X  r' 

then 

kl  <  r  — >  r'. 

Proof:  We  know  that  fc?  ns,  because  if  kl  were  ns  then  i(kl)(r)  would  be  ns  and  our 
hypothesis  would  be  false. 

Since  kl  \Zt-+ 1',  we  know  that  kl  has  the  form  kx  — » k{  A  . . .  A  k*  — ►  k'n.  Let 

S  =  {j  between  1  and  n  |  r  <  kj}. 

We  know  that  i(kl)(r)  is  not  ns  because  ns  ^  r'  cannot  be  true,  so  S  is  not  empty.  Let 

k'  =  -*  k'j  |  j  €  S}. 


112 


CHAPTER  2.  REFINEMENT  TYPE  INFERENCE 


Since  all  components  of  k1  appear  in  kl,  we  have 

Jfe?  <  k'. 


Let 

k"  =  A{r  — »  Aj  |  j  6  S}. 

Since  each  component  of  k'  is  a  subtype  of  the  corresponding  component  of  k",  we  have 

k'  <  k". 


Let 

=  r  -» A{jfe$  |  j  €  5}. 

Repeated  use  of  arrow-and-elim-sub  gives 

k"  <  km. 


Since  A{fc'-  |  j  e  5}  =  *(fc?)(r)  <  r'  is  a  hypothesis  of  this  lemma,  RCON-SUB  gives 

k'"  <  T  r\ 

Repeated  use  of  trans-sub  gives  fc?  <  r  — *  r#,  which  is  our  conclusion.  □ 

If  we  have  two  functions  f\  and  fo  with  common  domain  and  codomain,  and  we  can 
compare  elements  in  the  codomain,  then  we  can  naturally  compare  f\  and  f2  pointwise. 
That  is,  f\  is  greater  than  /2  if  for  all  z  in  their  common  domain,  f\ (x)  is  greater  than  /2(x). 
It  turns  out  that  this  ordering  when  used  on  i(k)  is  the  same  as  the  subtype  ordering  on  k. 

Lemma  2.84  (Ordering  on  i)  Ifkl  and  p?  refine  t—*t'  and  for  all  r  refining  t  we  have 

i(fc?)(r)  X  i(p?)(r) 


then 

Jfe?  <  p?. 

Proof:  If  fc?  =  ns,  then  for  all  r  refining  t  we  have  i(k?)(r)  =  ns,  so  *(p?)(r)  =  ns. 
This  can  only  be  the  case  if  p?  =  ns,  so  by  definition  of  ■<  we  have  kl  X  p?,  which  is  our 
conclusion. 

If  p?  =  ns  then  we  immediately  get  kl  X  p?  by  definition  of  X. 

Otherwise,  since  p?Cl->  t',  we  know  that p?  has  the  form  p\  p\  A  . . .  A  pm  -* p'm. 
By  the  definition  of  *,  for  all  j  between  1  and  m  we  have 

*(p?)(Pi)  <  Pj- 

By  our  hypothesis 

*(fc?)(Pi)  <  *(P?)(Pi)- 
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which  is  our  conclusion.  □ 

Now  we  can  show  that  i  preserves  all  the  information  about  its  first  argument.  This  is 
our  main  result  about  t;  the  remainder  of  the  argument  after  the  following  lemma  is  little 
more  than  repackaging  i  to  get  our  interpretation  function  I,  and  translating  the  following 
lemma  to  a  statement  about  I. 


Lemma  2.85  ( i  Preserves  Information)  Suppose  r?  and  rV  both  refine  t  — >  t'.  Then 

for  all  k  and  k'  refining  t  we  have  k  =  k1  implies  i(r?)(fc)  %  »W)  (2.46) 

if  and  only  if 

r?  =  r?'.  (2.47) 


Proof  of  (2.46)  implies  (2.47):  From  (2.46)  we  get 

for  all  k  and  k'  refining  t  we  have  k  =  k'  implies  i(r?)(fc)  x  i(rT)(k') 
Since  k  at,  we  can  choose  k'  =  k  and  we  have  k  =  k.  Thus 

for  all  k  refining  t  we  have  i(r?)(fc)  X  »(r?')(&) 
and  Lemma  2.84  (Ordering  on  i)  on  page  1 12  gives 

r?  <  r •?'. 


A  symmetric  argument  gives 

tT  <  r?, 

and  together  these  imply  our  conclusion. 

Proof  of  (2.47)  implies  (2.46):  From  (2.47)  we  get 

r?  <  r?', 


and  we  can  then  use  Lemma  2.81  (*  Monotone  in  First  Argument)  on  page  109  to  get 

i(r?)(Jfe)  X  i(rl')(k). 
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The  premise  of  the  implication  in  (2.46)  gives 

k  <  k', 

and  Lemma  2.80  (*  Monotone  in  Second  Argument)  on  page  108  gives 

'(r?)(*)  i  »(r *)(*'). 

Fact  2.78  (Transitivity  of  <)  on  page  108  gives 

*(r?)(fe)  X  i(r?')(fc'). 

A  symmetric  argument  gives 

•(>•  ?)(*')  i  »(<•?)(*), 

and  together  these  are  our  conclusion.  □ 

Now  we  will  repackage  i  as  a  function  mapping  equivalence  classes  to  equivalence 
classes.  First  we  must  define  some  notation  for  manipulating  equivalence  classes: 

Definition  2.86  If  rl  is  a  generalized  refinement  type,  then  the  equivalence  class  C(rl) 
containing  r?  is  the  set  {rl1  |  r?'  as  r?}. 

Definition  2.87  Ift  is  an  ML  type,  then  EC(t )  is  the  set  of  equivalence  classes  of  generalized 
refinements  oft,  or  in  symbols,  {C(r?)  |  rl  C  f }. 

We  shall  use  c  as  a  metavariable  standing  for  the  equivalence  class  of  a  refinement  type, 
and  c?  as  a  metavariable  standing  for  the  equivalence  class  of  a  generalized  refinement  type. 

Now  we  have  the  machinery  to  define  the  interpretation  of  refinement  types  as  a  mapping 
from  equivalence  classes  to  equivalence  classes: 

Definition  2.88  If  cl'  €  EC{t')  and  c  €  EC(t)  and  r?C<->  t',  then  we  write 

cl'  =  J(r?)(c) 

if  there  is  a  k  e  c  such  that  cl'  =  C(i(r?)(fc)). 

By  Lemma  2.80  (*  Monotone  in  Second  Argument)  on  page  108,  we  know  that  i(r?) 
is  a  function  that  maps  equivalent  refinement  types  to  equivalent  refinement  types.  Thus 
/(r?)  is  a  function.  We  can  also  show  that  I  maps  equivalent  refinement  types  to  equal 
functions: 


Lemma  2.89  (/  Preserves  Equivalence)  Suppose  kl  and  pi  refine  t  — >  t'.  Then 

im = /(p?) 


if  and  only  if 


kl «  pi. 


2.9.  FINITE  REFINEMENTS,  PRINCIPALITY 


115 


Proof:  By  definition  of  equality  for  functions  we  have  7(fc?)  =  7(p?)  if  and  only  if  for 
all  c  in  EC{t)  we  have  7(fc?)(c)  =  I(pl)(c).  By  definition  of  7,  this  is  true  if  and  only  if 
whenever  r  =  r'  we  have  i(kl)(r)  «  i(p?)(r').  By  Lemma  2.85  ( i  Preserves  Information) 
on  page  1 13,  this  is  equivalent  to  A?  =  pi.  □ 

Theorem  2.90  (Finite  Refinements)  For  each  ML  type  u  we  have  EC(u)  is  finite. 

Proof:  By  induction  on  it. 

Case:  u =uc  By  Assumption  2.8  (Finite  Predefined  Refinements)  on  page  31,  uc  has  only 
finitely  many  refinements,  so  it  can  have  only  finitely  many  equivalence  classes. 

Case:  u  =  ti  *...*tn  Any  refinement  of  u  must  have  the  form 

(r{  *  ...»  r^)  A  ...  A  (r™  *  ...  *  r™). 

By  Fact  2.23  (Tuplesimp  Sound)  on  page  41,  this  is  equivalent  to  a  refinement  type  of  the 
form  k\*  ...*kn.  By  TUPLE-SUB,  two  refinements  of  u  of  this  form  are  equivalent  if  and 
only  if  they  are  equivalent  componentwise.  Since  our  induction  hypothesis  tells  us  that 
there  are  only  finitely  many  equivalence  classes  for  each  component,  there  are  only  finitely 
many  equivalence  classes  of  tuples  without  a  toplevel  A.  Since  each  refinement  of  u  is 
equivalent  to  one  without  a  toplevel  A,  there  are  only  finitely  many  equivalence  classes  of 
refinements  of  u. 

Case:  t  =  u  — >u'  By  our  induction  hypothesis,  EC{u)  and  EC(u')  are  both  finite.  By 

Lemma  2.89  (7  Preserves  Equivalence)  on  page  114,  for  all  r  refining  t  we  have  C(r)  is 
uniquely  determined  by  7(r).  Since  7(r)  maps  elements  of  EC(u)  to  elements  of  EC{u'), 
there  are  only  finitely  many  distinct  values  for  7(r),  and  therefore  only  finitely  many  values 
of  C{r)  and  only  finitely  many  values  in  EC(t).  □ 

Finite  Refinements  straightforwardly  gives  us  principal  refinement  types.  Later  on  we 
prove  that  there  is  an  algorithm  that  computes  principal  refinement  types;  this  proof  can 
also  be  interpreted  as  a  proof  that  principal  types  exist,  but  it  has  the  disadvantage  of  being 
much  more  complex  than  the  simple  proof  we  give  here. 

Corollary  2.91  (Principal  Refinement  Types)  If 

VR  he:r 

then  there  is  a  k  such  that 

VR  h  e:k 


and  for  all  p  we  have 


VR  I ~  e:  p  implies  k  <  p. 
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We  prove  this  by  choosing  k  to  be  the  intersection  of  all  refinement  types  such  that 
VR  f-  e  :  k,  with  suitable  perturbations  to  ensure  that  this  intersection  is  finite. 


Proof:  By  Theorem  2.54  (Inferred  Types  Refine)  on  page  68,  there  is  a  t  such  that  rdf 
and 

rtom(VR)  h  e  ::  t.  (2.48) 

Let 

ac  —  {c  G  EC(t)  |  for  some  r  in  c  we  have  VR  h  e  :  r}. 

and  for  c  in  sc  let  kc  be  an  arbitrary  but  fixed  element  of  c.  By  Theorem  2.90  (Finite 
Refinements)  on  page  1 15,  EC(t )  is  finite.  Thus  ac  is  finite  and  we  can  choose 

k  =  A {ke  |  c  €  ac} 

without  creating  an  infinite  syntactic  object.  Now  we  have  to  prove  that  k  has  the  two 
properties  required  by  our  conclusions. 

Proof  of  VR  h  e  :  As:  By  construction  of  ac,  for  each  ke  there  is  a  k'c  such  that  kc  =  k'c  and 

VR  F  e  :  1 fe'. 

WEAKEN-TYPE  immediately  gives  VR  h  e  :  kc,  and  repeated  use  of  and- intro-type  gives 

VR  h  e  :  k. 


Proof  of  VR  1-  e  :  p  implies  k  <  p:  Suppose  VR  1 -  e  :  p.  By  Theorem  2.54  (Inferred 
Types  Refine)  on  page  68,  there  is  a  u  such  that/)  C  u  and  rtom(VR)  h  e  ::  u.  By  Lemma 
2.4  (Unique  Inferred  ML  Types)  on  page  27,  we  must  have  u  =  t.  Thus,  by  construction 
of  ac,  p  must  be  in  some  equivalence  class  c  in  ac.  Since  c  is  an  equivalence  class,  ke  =  p. 
By  repeated  use  of  and-elim-l-sub  and  and-elim-r-sub,  we  have 

k  <  p. 

Since  this  argument  is  valid  whenever  VR  h  e  :  p,  we  have 

VR  h  e  :  p  implies  k  <  p, 

which  is  our  second  conclusion.  □ 


2.10  Decidability 

This  section  will  describe  an  algorithm  for  finding  the  principal  refinement  type  of  an 
expression.  This  requires  being  able  to  list  one  representative  of  each  equivalence  class 
of  refinements  of  an  ML  type  and  being  able  to  decide  whether  one  refinement  type  is  a 
subtype  of  another.  These  last  two  algori.hms  are  mutually  recursive,  so  we  will  describe 
them  together  in  Subsection  2. 10. 1 .  Then  we  will  give  an  algorithm  for  finding  the  principal 
split  of  a  refinement  type  in  Subsection  2. 10.2.  A  notion  of  least  upper  bound  for  refinement 
types  is  defined  in  Subsection  2.10.3,  then  we  use  all  of  these  in  an  algorithm  for  deciding 
refinement  types  in  Subsection  2.10.4. 
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2.10.1  Deciding  Subtyping  and  Enumerating  Refinements 

Now  we  will  describe  procedures  for  determining  whether  one  refinement  type  is  a  subtype 
of  another  and  for  enumerating  the  refinements  of  an  ML  type.  The  strategies  fordoing  both 
of  these  are  very  straightforward  except  when  we  are  dealing  with  functional  ML  types. 

To  determine  whether  r  <  k  when  both  r  and  k  refine  a  functional  ML  type  t\  — » t2,  we 
check  whether,  for  all  p  refining  t\,  we  have  t(r)(p)  -<  i(k)(p).  If  this  condition  is  true  for 
all  p,  then  r  <  k. 

To  enumerate  all  refinements  of  a  functional  ML  type  ti~*t2,  we  enumerate  all  possible 
monotone  functions  i(r)  mapping  refinements  of  t\  to  generalized  refinements  of  t2,  and 
convert  each  function  to  a  refinement  type.  Converting  these  functions  to  refinement  types 
is  the  job  of  the  fntoref  procedure  described  below;  this  procedure  is  the  inverse  of  i, 
since  when  we  only  specify  the  first  argument  of  i,  it  maps  a  refinement  type  to  a  monotone 
function  from  refinement  types  to  generalized  refinement  types. 

We  will  describe  the  algorithms  for  computing  this  in  stages.  In  this  introduction  we 
will  briefly  list  the  functions  and  give  an  intuitive  idea  of  what  they  should  do.  Then 
in  Subsubsection  2.10.1.1  we  will  give  a  formal  specification  of  the  functions  along  with 
pseudocode  implementing  them.  Finally,  in  Subsubsection  2.10.1.2  we  will  prove  each 
function  satisfies  its  specification. 

The  functions  involved  are: 

Afn  ^Computes  the  intersection  of  refinement  types  in  s. 

botfn  ^Computes  the  least  refinement  of  t. 

allrefs  ^Returns  a  set  containing  one  representative  from  each  equivalence  class  of 
refinements  of  t. 

subtypep  r?  kl  £  Determines  whether  r?  •<  kl,  assuming  both  r?  and  fc?  refine  t. 

ifn  r?  p  Computes  i(r?)(p),  assuming  p  C  £  and  for  some  u  we  have 

fntoref  /  £  If  /  is  a  monotone  function  from  refinements  of  t  to  generalized  refinements 
of  some  u,  and  r  refines  t,  then  f(r)  «  i(fntoref  /)(r). 

2.10.1.1  Specifications  and  Definitions 

We  will  describe  the  algorithm  by  using  a  mixture  of  SML  and  mathematical  notation.  In 
this  notation,  we  use  braces  ({  })  to  denote  mathematical  sets,  not  SML  records.  We  will 
also  freely  use  ellipses  (. . .)  and  set  comprehensions  ({  |  })  when  the  meaning  is  obvious 
and  obviously  computable.  We  will  assume  an  infix  operator  x  takes  the  cross  product  of 
several  sets  of  refinement  types  and  combines  them  into  tuples;  for  example, 

{££,  jf}  x  {T i„0/}  x  {runit}  =  {tt  *  T k,®/  *  runit,  ff  *  T i*,/  *  runit}. 
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Afn  First  we  have  a  trivial  utility  procedure  to  compute  A  and  give  an  example  of  our 
notation  for  algorithms.  If  a  is  a  finite  set  of  refinement  types,  the  function  call  Afn  s  must 
return  A 3.  For  example, 

Afn  { tt,ff }  =  ttAff. 

We  define  Afn  as  follows: 

fun  Afn  {}  *  ns 
I  Afn  {r}  =  r 

I  Afn  ({r,li}Ui)  =  rA(Afn  ({fc}Us)) 

The  last  case  may  be  a  little  confusing  because  we  are  using  SML’s  destructuring  notation  to 
destructure  a  mathematical  object.  It  means  “whenever  the  argument  to  Afn  has  the  form 
{r,  k}  U  a,  the  result  is  r  A  (Afn  ({k}  U  3))”.  This  notation  is  vague  about  which  elements 
of  s  we  choose  to  name  r  and  k;  this  vagueness  (and  similar  vagueness  in  algorithms  that 
follow)  makes  no  important  difference,  and  we  shall  ignore  it. 

The  above  function  is  the  only  one  that  does  not  participate  in  the  mutual  recursion  to 
come. 

botf  n  The  function  call  botf  n  t  returns  the  least  refinement  of  t.  That  is,  if  r  C  t,  then 
(botf  n  t)  <  r.  The  code  for  botf  n  is: 


fun  botfn  t  =  A(allrefs  t) 


Note  that  there  may  be  values  of  ML  type  t  with  the  refinement  type  botfn  t;  for  example, 
if  have  a  datatype  d  and  with  no  declared  refinements,  there  will  be  only  one  refinement  of 
d;  call  it  T Then  botfn  d  =  T 4,  which  will  be  inhabited  by  all  values  with  ML  type  d. 

allref  s  The  function  call  allref  s  t  returns  a  list  of  one  representative  of  each  equiv¬ 
alence  class  of  refinements  of  t  the  refinements  of  t.  If  r  C  f,  then  there  must  be  a 
k  G  allref  s  t  such  that  r  =  k.  Also,  for  all  t  we  must  have  allref  s  t  is  finite. 

For  example, 

allref s  bool  =  {«,#,  T^,  -Li(W/}. 

It  would  be  consistent  with  the  specification  for  allref s  bool  to  return  {tt  A  tt,ff  A 
T »o,/,  T to,/,  tt  A  ff}.  The  code  for  allref  s  follows.  As  in  Standard  ML,  when  we  have 
multiple  mutually  recursive  procedures,  we  introduce  all  but  the  first  with  the  and  keyword 
instead  of  the  fun  keyword. 
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and  allrafs  (t\*...*tn)  »  allrefs  t\  x  ...  x  allrefs  tn 
I  allrefs  (£— »u)  = 

{fntoref  /  t  J 

/  is  a  function  from  allrefs  t  to  (allrefs  u)  U  {ns} 

and  /(botfn  £)  ^  ns 

and  for  all  r  and  k  in  allrefs  t  we  have 

subtypep  r  k  t  implies  subtypep  (/  r)  (/  A:)  u} 

.  ,  ,  def  , 

I  allrefs  tc  -  {re  |  re  IZ  tc} 

subtypep  The  function  call  subtypep  r?  k?  t  determines  whether  r?  X  Jfe?,  assuming 
that  both  r?  and  kl  refine  t.  For  example, 

subtypep  tt  ff  bool  =  true. 

The  code  for  subtype  follows;  note  that  it  uses  the  tuplesimp  and  r  cons  imp  functions, 
which  are  defined  on  pages  41  and  42,  respectively. 

and  subtypep  _  ns  _  =  true 

I  subtypep  ns  k  .  =  false 

I  subtypep  r  k  (t\  *  . . .  *  th)  - 

let  val  r\  * ...  *  =  tuplesimp  r 

val  k\  *  ...  *  kh  =  tuplesimp  k 

in 

for  j  in  1 . . .  h  we  have  subtypep  r,-  kj  tj 

end 

I  subtypep  r  k  — >  t2)  - 

for  all  pG  allrefs  t\  we  have  subtypep  (ifn  r  p  t\ )  (ifn  k  p  £()  t2 
I  subtypep  r  k  tc  * 

let  val  re  =  rconsimp  r 
val  kc  3  rconsimp  k 
in 

def 

re  <  kc 

end 

We  could  make  the  £i  — ►  t2  case  more  efficient  by  replacing  it  with 

I  subtypep  r  k  (t\  —>  t2)  = 

let  (k\  — >  k[  A  . . .  A  kn  — »  k'n)  =  k 
in 

for  all  j  in  1 ...  n  we  have  subtypep  (ifn  r  kn  t\)  k'n  t2 

end 

but  this  would  be  slightly  more  difficult  to  prove,  and  it  does  not  work  for  the  representation 
of  refinement  types  used  in  the  serious  exploration  of  efficiency  in  Chapter  7.  Thus  we  will 
stay  with  the  simpler  but  less  efficient  version. 
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ifn  The  function  call  if n  r?  p  t  computes  t(r?)(p),  assuming  that  for  some  u  we  have 
r?  c  t  — *u  and  p  Ct.  For  example, 

ifn  ( tt  —*  tt  A  ff  —>  ff)  -Lkooi  bool  =  it  A  ff 


and 

The  code  for  ifn  is: 


ifn  (tt— *tt)  ff  bool  =  ns. 


and  ifn  r?  p  t  * 

if  r?  =  ns  then  ns 
else 

let  val  fi  — +  r\  A  . . .  A  rn  — ►  a  r? 

in  Afn  {r^  |  h  G  1 . . .  n  and  subtypep  p  r*  f } 

end 


fntoref  The  function  fntoref  is  an  inverse  of  sorts  to  ifn.  If  /  maps  refinements  of  t 
to  generalized  refinements  of  some  other  ML  type,  and  /  is  monotone,  and  /( botfn  t)  is 
not  ns,  then  fntoref  ft  is  a  refinement  type  and  for  all  k  refining  t  we  have 

f(k)  «  *(fntoref  /  t,k). 


We  need  to  require  /  to  be  monotone  because  i  is  monotone  in  its  second  argument,  so 
the  equivalence  just  displayed  could  not  possibly  be  true  if  /  is  not  monotone.  We  need 
/(botfn  t)  to  be  something  other  than  ns  to  ensure  fntoref  ft  is  always  a  refinement 
type.  The  code  for  fntoref  is: 

and  fntoref  f  t  - 

Afn  {r  — *  f(r)  \  r  €  allref  s  t  and  f(r)  ^  ns} 


2.10.1.2  Soundness 

To  prove  these  algorithms  sound,  we  need  to  prove  they  always  terminate  and  they  fit  their 
specifications.  First  we  will  show  partial  correctness,  then  we  will  give  an  informal  proof 
of  termination. 


Theorem  2.92  (Subtype  Decidability)  All  of  the  functions  discussed  in  Subsubsec¬ 
tion  2.10.1.1  fulfill  their  specification  when  they  terminate. 


Proof:  By  induction  on  the  evaluation  of  the  function. 
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Ain  meets  its  specification  Trivial. 

botfn  meets  its  specification  We  need  to  show  that  if  r  c  t,  then  botfn  t  <  r.  By 
induction  hypothesis,  we  can  assume  that  allref  s  is  sound;  thus  there  is  a  k  in  allref  s  t 
such  that  r  =  k.  By  repeated  use  of  and-elim-l-sub  and  and-elim-r-sub  we  have 
A(allref  s  t)  <  k.  Then  TRANS-SUB  gives  A(allref  s  t)  <  r,  which  is  our  conclusion. 

allref  s  meets  its  specification  We  need  to  show  that  for  all  t  we  have  allref  s  t  is 
finite,  and  that  if  r  C  t,  there  is  a  k£  allref  s  t  such  that  r  =  k. 

Case:  allref  s  (f  i  *  ...  *  <n)  The  code  for  this  case  is 

fun  allref s  =  allref s  £i  x  ...  x  allref s  tn 

Suppose  r  C  t\  *  ...  *  tn.  Then  tuplesimp  r  must  be  defined  and  have  the  form 
ri  * . . .  *  r„,  and  soundness  of  tuplesimp  gives  tuplesimp  r  =  r\*...*rn.  By  induction 
hypothesis,  for  h  in  1 . . .  n  there  is  a  ph  in  allref  s  such  that  rh  =  ph ■  Then  TUPLE-SUB 
gives 

f*i  * . ..  *rn  ~  p\  *  ...  *  pn 

and  TRANS-SUB  gives 

r  =  pt  *  . . .  *  pn. 

The  definition  of  x  then  gives 

Pi  *  •  •  •  *  Pn  €  allref  s  t\  x.  ...  x  allref  s  tn. 

Thus  pi  *  ...  *  p„  is  the  member  of  allref  s  t  that  we  seek.  Since  the  cross  product  of  a 
finite  number  of  finite  sets  is  finite,  allref  s  t  is  a  finite  set,  so  we  are  done. 

Case:  allref  s  t  — >  u  The  code  for  this  case  is 

I  allref s  (t—*u)  = 

{fntoref  /  t  \ 

f  is  a  function  from  allref  s  t  to  (allref  s  u)  U  {ns} 

and  /(botfn  t )  7^  ns 

and  for  all  r  and  k  in  allref  s  t  we  have 

subtypep  r  k  t  implies  subtypep  (/  r)  (/  k)  «} 

Suppose  r  C  i  — ►  u.  Then  r  has  the  form  ri  — ►  r[  A  . . .  A  r„  — ♦  r'n.  Define 

f  =  Xk  | nS  if  t(r,  k)  =  ns 

'  (any  p  in  allref  s  u  such  that  p  =  i(r,  k )  otherwise. 
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We  will  show  that  fntoref  /  t  is  in  allref  s  t  — *  u,  and  that  r  =  fntoref  /  t. 

By  definition  of  i,  we  know  that  /( botfn  t)  is  r'j  A  ...  A  rj,,  which  is  certainly  not  ns. 
Since  i(r,  k )  is  monotone  in  k  we  know  that  /  is  monotone.  Thus  the  code  for  this  case  of 
allref  tells  us 

fntoref  /  t  is  in  allref  s  (t  — *  u). 


Let  r'  —  fntoref  /  t.  Since  fntoref  is  sound,  we  know  that 
for  all  k  refining  t  we  have  f(k)  ss 
By  definition  of  /  we  have 

for  all  k  refining  t  we  have  f(k)  %  i(r,  k). 


By  transitivity  of  »,  these  imply 

for  all  k  refining  t  we  have  i(r\  k)  «  i(r,  k). 


By  Lemma  2.85  (i  Preserves  Information)  on  page  1 13,  this  implies  r'  =  r. 

We  know  that  allref  s  is  finite  because  by  induction  allref  s  t  and  allref  s  u 

are  finite,  and  there  are  finitely  many  functions  from  a  finite  set  to  a  finite  set. 


Case:  allrefs  tc 


The  code  for  this  case  is 


I  allrefs  tc  =  {nc  |  rc  E  tc} 

By  Assumption  2.8  (Finite  Predefined  Refinements)  on  page  31,  allrefs  tc  is  finite. 

Suppose  r  C  tc.  Then  r  must  have  the  form  A  ...  A  rcn,  where  for  all  i,  rci  (Z  tc. 
Then  Lemma  2.24  (Refinement  Constructor  Intersection)  on  page  41  gives 

def  dcf 

r  =  rci  A  ...  A  rc„. 


By  Theorem  2.21  (Subtypes  Refine)  on  page  36,  rci  A  ...  A  7rn  C  tc\  this  can  only  be 

.  .  def  def  d  def  def 

inferred  by  using  RCON-REF  with  the  premise  rci  A  ...  A  rcn  E  tc.  Thus  rc(  A  ...  A  rcn  G 
allrefs  tc,  which  is  what  we  wanted  to  show. 


subtypep  meets  its  specification  We  need  to  show  that  if  both  r?  and  A?  refine  t,  then 
subtype  r?  fc?  t  returns  true  if  and  only  if  r?  ^  fc?. 


Case:  subtypep  r?  ns  _ 


The  code  for  this  case  is 


and  subtypep  _  ns  _  =  true 
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The  definition  of  gives  r?  X  ns,  which  is  what  we  wanted  to  show. 

The  code  for  this  case  is 


Case:  subtypep  ns  fc?  _ 


I  subtypep  ns  _  _  =  false 

^  A?  is  false,  which  is  what  we  wanted  to  show. 
The  code  for  this  case  is 


The  definition  of  <  tells  us  that  ns 


Case:  subtypep  r  k  (t\  *  . . .  *  f„) 


I  subtypep  r  k  (t\  *  . . .  *  th)  = 

let  val  r\  * ...  *rh  -  tuplesimp  t 
val  k\  *  ...  *  kh  *  tuplesimp  k 
in 

for  j  in  1 . . .  h  we  have  subtypep  tj  kj  tj 

end 

Since  r  and  k  both  refine  t\*  ...*tn,  tuplesimp  r  and  tuplesimp  A:  are  defined  and 

tuplesimp  r  has  the  form  *  ...  *  rh 


and 


tuplesimp  k  has  the  form  kx*  ...*  kh. 
By  soundness  of  tuplesimp. 


and 


r  =  T\  *  ...  *  Th 


k  =  k\  *  ...*kh- 


Suppose 

By  trans-sub,  this  is  equivalent  to 


r  <  k. 


(2.49) 


r\*...*rh<kx*...*kh. 

By  TUPLE-SUB  and  Corollary  2.27  (TUPLE-SUB  Inversion)  on  page  45,  this  is  equivalent  to 

for  j  in  1 ...  h  we  have  r j  <  kj. 

By  induction  hypothesis,  subtypep  is  sound,  so  this  is  equivalent  to 

for  j  in  1 . . .  h  we  have  subtypep  Tj  kj  tj .  (2.50) 

Summarizing  the  above  argument,  (2.49)  is  equivalent  to  (2.50).  By  definition  of  subtype, 
this  is  our  conclusion. 

Case:  subtypep  r  k  (fi— >$2) 


The  code  for  this  case  is 
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I  subtypep  r  k  (ti  — >t2)  a 

for  all  p€  allrefs  tx  we  have  subtypep  (ifn  r  p  tx)  (ifn  k  p  tx)  t2 
Suppose 

r  <  k  (2.51) 

By  Lemma  2.84  (Ordering  on  *)  on  page  112  and  Lemma  2.81  (t  Monapne  in  First 
Argument)  on  page  109,  this  is  equivalent  to  m 

for  all  p'  C  t\  we  have  *(r)(p')  <  i(k)(p').  ...  (2.52) 

Since  we  can  assume  by  induction  that  recursive  calls  to  allrefs  are  sound,  for  all  p'  \Z  tx 
there  is  a  p  in  allrefs  tx  such  that  p  =  p'.  This  and  Lemma  2.81  (i  Monotone  in  First 
Argument)  on  page  109  give 

for  all  p'  C  t\  there  is  a  p  in  allrefs  tx  such  that 
i(r)(p)  %  t(r)(p')  and  i(k)(p)  «  *(fc)(p')- 

We  can  use  this  with  Fact  2.78  (Transitivity  of  <)  on  page  108  on  (2.52)  to  git 

for  all  p  in  allrefs  t\  we  have  *(r)(p)  <  i(k)(p). 

By  induction,  we  can  assume  that  recursive  calls  to  subtypep  and  ifn  are  sound,  so  this  is 
equivalent  to 

for  all  p  in  allrefs  t\  we  have  subtypep  (ifn  r  p  tx)  (ifn  k  p  tx)  t2  (2.53) 
Summarizing  the  argument  so  far,  (2.5 1)  is  equivalent  to  (2.53).  This  is  our  conclusion. 

Case:  subtypep  r  k  tc 

The  code  for  this  case  is 


I  subtypep  r  k  tc  ~ 

let  val  rc  =  rconsimp  r 
val  kc  =  rconsimp  k 
in 

def 

rc  <  kc 

end 

By  assumption,  r  and  k  refine  tc;  therefore  both  calls  to  rconsimp  are  valid.  By  Fact  2.23 
(Tuplesimp  Sound)  on  page  41,  r  =  rc  and  k  =  kc. 

Suppose  r  <  k.  By  TRANS-SUB,  this  is  equivalent  to  rc  <  kc;  by  RCON-SU&  and  Fact 

def 

2.29  (RCON-SUB  Inversion)  on  page  45,  this  is  equivalent  to  rc  <  kc.  Summarizing  the 

def 

argument  so  far,  r  <  k  if  and  only  if  rc  <  kc.  By  definition  of  subtypep,  this  is  our 
conclusion. 


* 


ifn  meets  its  specification  The  code  for  ifn  is 
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and  ifn  r  p  t  * 

let  val  rt  — *  r[  A  . . .  A  rn  — ►  r'n  =  r 

in  Afn  {rJJ  fc  €  1  ...n  and  subtypep  p  t} 

end 

and  we  need  to  show  that  if  r  □  t  — >u  and  p  C  t  then  ifn  r  p  t  =  t(r,p).  This  is 
obviously  correct,  since  we  can  assume  by  induction  that  the  recursive  calls  to  subtypep 
are  sound. 

fntoref  meets  its  specification  The  code  for  f  ntoref  is 
and  fntoref  f  t  = 

Afn  {r  — ►  /(r)  |  r  €  allref  s  t  and  f(r)  /  ns} 

and  we  need  to  show  that  if  there  is  a  u  such  that 

/  maps  refinements  of  t  to  generalized  refinements  of  u 


and 


/  is  monotone 


and 

then  for  all  k  c  t  we  have 


/(botfn  t)  is  not  ns. 


f(k)  «  z(fntoref  /  t){k). 

Since  /(botfn  t )  is  not  ns,  we  know  that  (botfn  t)  — ►  /(botfn  t )  is  one  of  the  com¬ 
ponents  in  fntoref  /  t.  Thus  fntoref  ft  is  not  ns,  and  we  can  let  r  -  fntoref  /  f . 

Suppose  A:  c  f.  By  definition  of  t, 

i(r)(k)  =  A {/(p)  |  <  P>- 

SELF-SUB  gives  k  <  k,  so  /(&)  is  in  {/(p)  |  A:  <  p}  and  Fact  2.77  (A  Intro  Sub)  on 
page  107  gives 

/(At)  <  A{/(p)  |  A:  <  p}. 

Since  f  is  monotone,  k  <  p  implies  f(k)  <  /(p).  Thus  all  elements  of  {/(p)  |  k  <  p}  are 
greater  than  f(k),  so  Fact  2.76  (A  Elim  Sub)  on  page  107  gives 

A {/(,,)  |  A  <  p}  <  f(k). 

Thus  i(r)(k)  «  /(As),  which  is  our  conclusion.  □ 

Theorem  2.93  (Termination  for  subtypep  and  allref  s)  All  algorithms  defined  in  Sub¬ 
subsection  2.10.1.1  terminate  for  all  inputs. 
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The  function  Af  n  terminates  because  its  argument  is  a  finite  set.  An  infinite  execution 
of  any  other  function  must  involve  infinitely  many  recursive  calls  to  some  function,  call  it 
/.  Examination  of  the  code  tells  us  /  must  have  an  argument  that  is  an  ML  type,  and  that 
ML  type  must  get  smaller  from  one  call  to  /  to  the  next.  Since  all  ML  types  are  finite,  this 
is  a  contradiction.  Thus  all  executions  are  finite.  □ 


2.10.2  Deciding  Splits 

In  the  refinement  type  inference  algorithm  we  present  in  Subsection  2.10.4,  the  split-type 
rule  is  always  done  as  early  as  possible;  each  variable  is  split  exactly  once  when  it  is 
added  to  the  variable  environment.  For  example,  if  the  algorithm  is  considering  what  might 
happen  if  x  has  type  T iooy ,  it  will  split  this  into  the  possibilities  x  :  tt  and  *  :  ff  when  x  is 
added  to  the  environment,  and  it  will  not  consider  splitting  x  again.  The  appropriate  split 
to  use  is  the  principal  split  of  the  type  of  x ,  as  discussed  in  Subsubsection  2.6.2.2.  This 
Subsection  gives  a  procedure  for  computing  principal  splits. 


2.10.2.1  Computing  Principal  Splits 

We  will  give  a  constructive  proof  that  principal  splits  exist  which  can  also  be  used  as  an 
algorithm  for  computing  them.  But  first  we  will  give  an  algorithm  anysplit  that  returns 
a  useful  split  of  a  refinement  type  if  there  is  one.  If  there  are  none,  then  anysplit  returns 
the  singleton  set  containing  its  argument. 

fun  anysplit  r  {ty  *  ...  *  t^)  - 

let  val  rx  *  ...*rh  -  tuplesimp  r 
in 

anysplit  ry  x  . . .  x  anysplit 

end 

I  anysplit  r  tc  = 

let  val  re  =  r  cons  imp  r 
in 

if  re  has  a  useful  predefined  split  sc 
then  sc 
else  {r} 

end 

I  anysplit  r  (£j  — ►  tz)  -  {r} 

Soundness  of  his  algorithm  follows  by  induction  on  the  ML  type  argument. 

Assuming  anysplit  works,  it  is  straightforward  to  find  a  principal  split.  Just  split  all 
of  the  fragments  so  long  as  there  is  one  with  a  useful  split,  and  then  use  elim-split  to 
eliminate  as  many  elements  as  possible. 
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Theorem  2.94  (Principal  Split  Existence)  Ifr  c  t  and  r  x  s  then  we  can  construct  an  s' 
that  is  a  principal  split  of  r. 

Proof:  Let  =  s.  For  i  >  1,  if  there  is  an  element  of  S{  with  a  useful  split  s ",  then  let 

a»+i  =  («»  -  {r<})  U  s". 

This  process  has  to  stop  eventually,  because  by  definition  of  useful  the  elements  added  to 
each  S{  are  strictly  subtypes  of  the  elements  we  take  from  3it  and  t  has  only  finitely  many 
refinements.  Let  n  be  the  last  value  of  i;  by  construction,  we  know  that 

for  all  k  in  sn,  all  splits  of  k  are  useless. 

By  repeated  use  of  TRANS-SPLIT, 


for  all  i  we  have  r  x  s^ 

Once  we  eliminate  as  many  elements  as  possible  from  sn  we  will  have  our  result.  This  is 
straightforward:  arbitrarily  order  the  elements  of  3n  such  that 

{Asj =  Sn. 


Let 

s'  =  {&,•  |  j  in  1 . . .  m  and  whenever  kh  €  sn  and  kj  <  fa  we  have  fa  =  fa  and  h  >  j.}. 

By  construction,  EUM-SPLIT  can  eliminate  no  more  elements  from  s'.  By  repeated  use  of- 
elim-SPLIT,  r  x  s'.  Since  s'  is  a  subset  of  s, 

for  all  k  in  s',  all  splits  of  k  are  useless. 

Thus,  by  Lemma  2.46  (Fragments  of  Principal  Split  have  Useless  Splits)  on  page  58,  s'  is 
a  principal  split  of  r.  □ 


2.10.3  Join 

A  refinement  type  for  a  case  statement  is  an  upper  bound  of  the  refinement  types  of  the 
reachable  branches,  and  the  principal  refinement  type  of  the  case  statement  is  the  least  upper 
bound  of  the  principal  refinement  types  of  the  reachable  branches.  Therefore  we  need  to 
be  able  to  compute  least  upper  bounds  of  refinement  types.  For  example,  assume  that 
we  have  an  ML  datatype  type  blist  with  only  the  refinement  T  and  a  function  emptyp 
with  refinement  type  T uut  — *  and  a  value  nil  ()  of  type  T The  intuition  is  that 

emptyp  determines  whether  the  list  is  empty,  but  the  programmer  has  not  declared  interest 
in  the  distinction  between  empty  blist's  and  nonempty  blist's,  so  refinement  type  inference 
will  not  notice  this.  Then  the  expression  emptyp  (nil  ())  has  the  principal  type  T boot, 
and  computing  the  principal  type  of  the  statement 
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case  emptyp  (nil  ())  of 

true  =>  fn  ignored:  tunit  =>  true  () 

I  false  =>  fn  ignored :  tunit  =>  false  () 
end:  bool 

requires  finding  the  least  upper  bound  of  the  principal  types  of  the  expressions  true  () 
and  false  (),  yielding  T In  general,  the  least  upper  bound  will  not  always  exist;  in 
that  case  the  case  statement  has  no  refinement  type.  For  example,  assuming  x  has  the  type 
tt  — >  it  and  y  has  the  type  ff  ff,  trying  to  find  a  type  for  the  statement 

case  emptyp  (nil  ())  of 

true  =>  fn  ignored :  tunit  =>  x 
I  false  =>  fn  ignored:  tunit  =>  y 
end :  bool  — >  bool 

requires  finding  a  least  upper  bound  for  tt  — » tt  and  ff  — ►  ff .  There  is  none,  and  this  statement 
has  no  refinement  type.  (The  reader  may  object  that  we  cannot  write  an  expression  that 
has  the  principal  type  tt  —* tt.  This  is  true  for  the  language  constructs  introduced  in  this 
chapter,  but  it  will  be  false  after  we  introduce  the  <3  operator  in  Chapter  6.  In  any  case,  it 
is  consistent  with  the  theory  to  hypothesize  such  a  variable.) 

We  will  call  these  least  upper  bounds  “joins”  rather  than  “disjunctions”  or  “unions”. 
Calling  them  disjunctions  would  conflict  with  existing  nomenclature  used  in  type  theory. 
Calling  them  unions  would  be  misleading  because  if  we  interpret  the  refinement  types  as 
sets,  the  interpretation  of  the  join  of  two  refinement  types  may  be  a  proper  superset  of  the 
union  of  their  interpretations.  For  example,  the  join  of  the  refinement  types  T  — ►  tt  and 
T ilut  -*  ff  is  T ui,t  —*  T too /.  The  function  emptyp  is  in  the  interpretation  of  T — ►  T^/, 
but  it  is  not  in  the  interpretations  of  either  T  w,t  — *  tt  or  T  w„t  — >  ff,  so  it  is  not  in  the  union 
of  their  interpretations. 

According  to  John  Reynolds  [personal  communication,  1993],  type  inference  for 
Forsythe  uses  a  similar  notion  of  least  upper  bounds  for  the  same  purpose. 


2.103.1  Definition  of  Join 

The  least  upper  bound,  if  it  exists,  is  the  greatest  lower  bound  of  all  of  the  upper  bounds. 

Definition  2.95  Ifr ?  □  t  and  fc?  C  t  then  we  define 

r?  U  fc?  =  A{p  £  allref  s  t  |  r?  ■<  p  and  kl  ■<  p}. 


We  would  say  “p  C  t”  instead  of  “p  €  allref  s  <”  except  A  is  meaningless  for  infinite 
sets,  and  if  we  compare  refinements  of  t  by  mathematical  equality  rather  than  refinement 
type  equivalence,  there  are  infinitely  many  refinements  of  t. 
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We  also  define  a  join  operator  for  refinement  type  constructors: 

def  def 

Definition  2.96  If  rc  C  tc  and  kc  C  tc  then  we  define 

def  def  .  .  def  def 

rc  U  kc  =  A  {pc  I  rc  <  pc  and  kc  <  pc}. 

def 

If  the  set  is  empty,  then  rc  U  kc  is  undefined. 

It  is  easy  to  see  that  r?  U  As?  is  an  upper  bound  of  r?  and  kl  in  the  X  ordering;  we  can 
derive  r?  X  rl  U  fc?  by  using  the  definition  of  Li  and  repeated  use  of  Fact  2.77  (A  Intro 
Sub)  on  page  107. 

It  is  also  easy  to  see  that  it  is  a  least  upper  bound;  if  p  is  an  upper  bound  of  r?  and  A:?,  it  is 
one  of  the  components  in  r?  U  As?,  so  repeated  use  of  AND-ELIM-R-SUB  and  AND-ELIM-L-SUB 
gives  rl  U  As?  X  p.  The  definition  of  <  tells  us  that  ns  is  also  an  upper  bound  of  r?  and  As? 
and  that  r?  U  As?  ■<  ns. 

We  can  effectively  compute  LI  because  allref  s  and  ■<  are  both  computable.  Unfortu¬ 
nately,  the  obvious  algorithm  derived  directly  from  the  definition  is  inefficient  because  the 
size  of  the  set  returned  by  allref  s  is  exponential  in  the  size  of  the  argument  to  allref  s. 
In  this  section  we  will  present  a  more  efficient  algorithm. 

If  the  obvious  slow  algorithm  were  used  to  find  tt  — ►  tt  LI  it  — ►  ff,  it  would  first  find 
allref  s  {bool  — >  bool)  and  then  take  the  intersection  of  all  types  in  that  set  that  are  greater 
than  both  tt  — >  tt  and  tt  —*  ff.  The  algorithm  presented  in  this  subsection  would  only, 
need  to  evaluate  allref  s  bool.  The  algorithm  presented  here  is  still  exponential  though; 
for  instance,  it  will  evaluate  allref s  {bool— *  bool)  if  asked  to  find  {tt  — >  tt)  — *  tt  LI 
(«->#)-»«. 

Theorem  2.97  (Join  is  Decidable)  There  is  an  algorithm  joinf  mapping  two  generalized 
refinement  types  and  an  ML  type  to  a  generalized  refinement  type  such  that  if 

rl  C  t 


and 

then  all  of  the  following  are  true: 


kl  c  t 


r?  <p  and  kl  -<p  implies  joinf  r?  kl  t  -<p 


rl  ^  joinf  r?  kl  t 
kl  d  joinf  rl  kl  t 

computation  of  joinf  rl  kl  t  terminates. 
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Proof:  We  will  present  the  definition  of  joinf  as  we  prove  it  correct.  The  proof  is  by 
induction  on  t.  In  each  case  we  will  omit  the  proof  of  kl  X  joinf  r?  k ?  t  because  it  is 
essentially  the  same  as  the  proof  of  r?  X  joinf  r?  As?  t. 

Since  least  upper  bounds  are  unique,  our  conclusion  is  equivalent  to 

joinf  r?  fc?  £  «  r?  U  fc?. 


Case:  joinf  ns  _  or  joinf  _  ns 


This  case  reads 


fun  joinf  ns  _  _  =  ns 
I  joinf  _  ns  _  =  ns 


Both  of  these  cases  are  trivial.  In  all  future  cases,  we  will  assume  that  r  and  k  are  not  ns. 


Case:  joinf  r  k  (.tx  *  . . .  *  tK) 


This  case  reads 


r  k  (£,*...*  £fc)  = 
val  rt  * ...  *Th  =  tuplesimp  r 
val  k\  *  kh  =  tuplesimp  k 
in 

if  for  j  in  I ...  h  we  have  (joinf  tj  kj  £,)  ^  ns 
then  (joinf  rj  ky  tx)  (joinf  rh  kh  th) 

else  ns 

end 


SubCase:  r  <  p  and  k  <  p  implies  (joinf  r  k  t\  *  ...  *  £/,)  <  p 


Suppose  r  <  p  and 


k  <  p.  By  Lemma  2.22  (Tuple  Intersection)  on  page  40,  there  are  p\  through  pn  such  that 
Pi  *  ...  *  Ph  =  P-  By  TRANS-SUB,  Corollary  2.27  (Tuple-sub  Inversion)  on  page  45,  and 
soundness  of  tuplesimp,  we  have 


for  j  in  1 . . .  h  we  have  Tj  <  pj  and  kj  <  pj. 

By  induction  we  can  assume  that  recursive  calls  to  joinf  are  sound,  so  this  implies 

for  j  in  1 ...  h  we  have  joinf  Tj  kj  tj  <  Pj  (2.54) 

and  then  tuple-SUB  and  trans-sub  give 

(joinf  t*i  k\  £,)*...*  (joinf  rh  kh  th)  <  p. 

(2.54)  tells  us  that  for  j  in  1 . . .  h  we  have  (joinf  r,-  kj  tj)  ±  ns,  so  the  definition  of 
joinf  gives 

joinf  t  k  (£j  *...*£„)<  p, 
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which  is  our  conclusion. 

SubCase:  r  X  joinf  r  k  t  By  Fact  2.23  (Tuplesimp  Sound)  on  page  41  we  know  that 
pi  * ...  *  p*  =  r.  By  soundness  of  the  recursive  call  to  joinf, 

for  j  in  1 ...  h  we  have  r j  X  joinf  rj  kj  tj. 

If  any  of  the  joinf  rj  kj  tj' s  are  ns,  then  the  definition  of  X  gives 

r  X  ns. 

Otherwise  TUPLE-SUB  and  TRANS-SUB  give 

r  <  (joinf  rj  kx  ii)  *  ...  *  (joinf  rh  kh  th). 

Either  way,  by  definition  of  this  case  of  joinf  we  have 

X  joinf  r  k  ( ), 

Trivial. 

| Case:  joinf  r  k  ( tx-*t2 )  |  The  code  for  this  case  uses  the  ifn  function  defined  on 
page  120  to  compute  the  interpretation  i  of  a  refinement  type.  Here  it  is: 

I  joinf  r  k  (<!  — »■  f^)  ~ 

A{p—+ joinf  (ifn  r  p  ti)  (ifn  k  p  <!)  t2  \ 
p  €  allref  s  tx  and 

(joinf  (ifn  r  p  t\)  (ifn  k  p  t\)  t2)  i=-  ns} 

Before  showing  that  this  case  of  joinf  works  reasonably,  we  need  to  show  that  its  inter¬ 
pretation  works  reasonably.  Formally,  we  will  start  by  showing  that  if  p  C  tx  then 

t( joinf  r  k  (<i i2))(?)  ~  »(p)(p)  U  t(fc)(p). 

Suppose  p  is  given  and  p  C  tx.  Consider 

*(joinf  r  k  (ii  -» t2))(p). 

By  definition  of  joinf,  this  is  equal  to 

*(A{p'  —►  joinf  (i(r)(p'))  (i(fc)(p'))  h\ 
p'  €  allref  s  t\  and 

(joinf  (*(r)(p'))  (*(fc)(p'))  t2  ±  ns )})(p) 


T 

which  is  our  conclusion. 
SubCase:  joinf  terminates. 


(2.55) 
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and  by  definition  of  »,  this  is  equal  to 


A{joinf  (i(r)(p'))  (*(*)(?'))  h  | 
p'  €  allrefa  t\  and 

(joinl  (*(r)(p'))  (*(*)(?'))  *2)  ^  ns  and 
P  <  P'b 


(2.56) 


By  our  induction  hypothesis. 


joinf  (»(r)(p'))  (»(*)(p'))  h  *  *(r)(p')  U  *(*)(?'). 


Thus  (2.56)  is  «  to 


A{»(r)(p')  U  »(*)(?')  | 
p'  €  allrefs  <1  and 

(joinf  (»(r)(p'))  ( i(k)(p '))  t2)  #  ns  and 
P<P'} 


(2.57) 


By  Lemma  2.80  (*  Monotone  in  Second  Argument)  on  page  108  and  monotonicity  of  U, 

P  <  ?'  implies  *(r)(p)  U  i(k)(p)  <  i(r)(p')  U  i(k)(p'). 

Since  we  can  eliminate  components  from  the  set  in  (2.57)  that  are  known  to  be  greater  than 
other  components  in  (2.57)  we  know  that  (2.57)  is  equivalent  to 

A{*(r)(p)  u  *(*)(?)  I  (joinf  (i(r)(p))  (*(*:)(?))  *2)  ^  ns}. 

By  our  induction  hypothesis,  joinf  (*(r)(p))  (i(fc)(p))  t2  is  ns  if  and  only  if  t(r)(p)  U 
i(fc)(p)  is  ns.  Thus  this  simplifies  to 


i(r)(p)  U  i(k)(p). 

Summarizing  (2.55)  through  (2.58),  if  p  C  t\  then 

i(  joinf  r  k  (it -» *2))(p)  ~  *(r)(p)  U  i(fc)(p). 


(2.58) 


(2.59) 


SubCase:  r  ^p  and  k  X  p  implies  joinf  r  k  (ii  — *  t2)  X  p  Suppose  r  <  pandk  <  p. 
By  Lemma  2.81  (*  Monotone  in  First  Argument)  on  page  109  we  have 

for  all  p'  C  t\  we  have  t(r)(p')  ■<  *(p)(p') 

and  likewise  for  k  gives 

for  all  p'  C  t\  we  have  *(&)(p')  X  t(p)(p'). 

Since  U  is  a  least  upper  bound,  this  implies 


for  all  p'  C  fi  we  have  t(r)(p')  u  i(k)(p')  <  *(p)(p'). 
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and  (2.59)  gives 

for  all  p '  Cl  t\  we  have  i(  joinf  r  k  {t\—*  t2))(p')  X  *(p)(p')> 
and  Lemma  2.84  (Ordering  on  t)  on  page  1 12  gives 

r  k  (t\  t2)  X  p, 


Since  U  is  a  least  upper  bound,  we  have 

for  all  p  C  it  we  have  *(r)(p)  X  i  (r)(p)  U  t(fc)(p). 

By  (2.59)  and  Lemma  2.81  (*  Monotone  in  First  Argument)  on  page  109,  this  implies 
for  all  p  C  t\  we  have  i(r)(p)  X  i(joinf  r  k  t\—>  f2)(p)  U  t(fc)(p). 

By  Lemma  2.81  (*  Monotone  in  First  Argument)  on  page  109,  this  implies 

r  X  joinf  r  k  t\  - *t2 , 


join! 

which  is  our  conclusion. 

SubCase:  r  X  joinf  r  A;  (it  — »•  £2) 


which  is  our  conclusion. 


SubCase:  Termination 


The  only  loop  in  this  code  is  over  a  finite  set,  and  by  induction 


we  can  assume  that  the  recursive  calls  to  joinf  terminate. 


Case:  joinf  r  k  tc 


The  code  for  this  case  uses  rconsirap,  which  is  defined  on 


page  2.6.1.  Here  is  the  code: 


I  joinf  r  k  tc  = 

let  val  rc  =  rconsimp  r 
val  kc  -  rconsimp  k 
in 

def 

if  rc  U  kc  is  undefined 

then  ns 

def  , 

else  it  U  «c 

end 


SubCase:  r  X  p  and  Hp  implies  joinf  r  k  tc  X  p 


Suppose  r  <  p  and  k  <  p.  Then 


p  C  tc,  so  by  Lemma  2.24  (Refinement  Constructor  Intersection)  on  page  41  there  is  a  pc 
such  that  p  =  pc.  Fact  2.25  (Rconsimp  Sound)  on  page  42  gives 


r  =  rc 
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and 


k  =  i fee. 


def  def  def 

Fact  2.29  (RCON-SUB  Inversion)  on  page  45  gives  nc  <  pc  and  kc  <  pc.  Therefore  nil  kc 
is  defined  and 

def  def 

nc  U  kc  <  pc. 

By  RCON-SUB,  TRANS-SUB,  and  the  definition  of  this  case  of  joinf,  this  implies 
join!  r  k  tc  is  not  ns  and 

join!  r  k  tc  <  p. 


By  definition  of  this  implies 


which  is  our  conclusion. 


join!  r  k  tc  ■<  p. 


SubCase:  r  -<  joinf  r  k  tc  If  joinf  r  k  tc  is  ns,  then  by  definition  of  ^  we  are 


done. 

def  .  def 

Otherwise,  nc  U  kc  is  defined.  By  soundness  of  r  cons  imp,  nc  =  r.  By  properties  of  U , 

def  def 

rc  <  rc  U  kc. 

Using  RCON-SUB,  TRANS-SUB,  and  the  definition  of  joinf,  this  implies 


def 


r  <  joinf  r  k  tc, 


which  is  our  conclusion. 


SubCase:  Termination 


Trivial. 


We  will  also  define  a  simple  function  s  joinf  that  finds  the  least  upper  bound  of  a  finite 
set  of  generalized  refinement  types: 


fun  sjoinf  t  {}  =  botfn  t 

I  sjoinf  t  ({r?}  U  i?)  =  joinf  r?  (sjoinf  t  s?)  t 


We  use  botfn  t  as  a  base  case  for  this  recursive  function  because  for  all  r  refining  t  we 
have 

(botfn  t)  U  r  =  A {p  €  allref  s  t  |  r  X  p  and  botfn  t  X  p} 

=  A{p  €  allref  s  t  j  r  ■<  p} 

=  r. 
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2.10.4  Deciding  Refinement  Types 

In  this  subsection  we  will  give  an  algorithm  called  infer  and  prove  that  it  finds  principal 
refinement  types.  First  in  Subsubsection  2.10.4.1  we  will  give  an  overview  of  the  algorithm 
by  giving  examples  of  how  it  works  for  each  case  in  the  syntax.  Th'-n  in  Subsubsec¬ 
tion  2.10.4.2  we  will  give  a  technical  lemma  that  makes  the  proof  much  simpler.  Finally  in 
Subsubsection  2.10.4.3  we  will  describe  the  algorithm  infer  and  prove  it  correct. 

This  algorithm  is  similar  to  the  one  actually  implemented.  The  main  difference  between 
the  algorithm  described  here  and  the  implementation  is  the  evaluation  order;  infer  is  eager 
and  the  implementation  is  lazy.  For  example,  when  confronted  with  the  expression 

f  n  x :  bool  => 
case  x  of 

true  =>  fn  _  =>  false  () 

I  false  ->  fn  _  =>  true  () 
end:  bool 

inf  er  eagerly  finds  a  type  for  this  by  assuming  x  can  have  all  possible  refinements  of  bool, 
yielding  the  result 

-L  boot  *  -L  bool  A 1 1  >  ff  A  ff  ►  tt  AT  bool  *  T  boot  • 

The  implementation  postpones  evaluation  as  long  as  possible.  It  returns  a  function  that,  for 
instance,  when  passed  tt,  will  return  ff.  This  strategy  is  faster  than  eagerness  when  we  are 
only  interested  in  evaluating  functions  on  a  few  points  in  their  domain.  If  pursued  in  the 
simplest  way,  this  strategy  would  be  slower  than  infer  if  we  evaluate  the  function,  say,' 
100  times  at  tt.  The  implementation  is  able  to  perform  well  in  this  case  by  memoizing.  We 
will  discuss  the  implementation  in  more  detail  in  Chapter  7. 


2.10.4.1  Overview  of  the  Algorithm 

In  this  section  we  will  present  the  algorithm  informally  by  giving  examples  of  how  it 
behaves  for  each  variety  of  syntax. 

The  algorithm  has  one  invariant  that  needs  to  be  maintained:  all  types  in  the  environment 
must  have  no  useful  splits.  This  requires  finding  a  principal  split  every  time  we  add  a  variable 
binding  to  the  environment.  The  only  syntax  that  adds  variable  bindings  to  the  environment 
is  abstractions,  so  all  the  responsibility  for  maintaining  this  invariant  falls  on  that  case  of 
the  algorithm. 


Variable  references  This  case  is  trivial;  just  look  the  variable  up  in  the  variable  envi¬ 
ronment.  For  example,  in  the  environment  [x  :=  tt],  the  type  we  infer  for  x  is  tt. 


Abstractions  Except  for  the  fact  that  we  have  to  maintain  our  invariant,  we  could  find  a 
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principal  type  for  fn  x-.bool  =>  or  (not  x,  x)  using  the  following  procedure:  for  each 
refinement  of  bool,  bind  x  to  that  refinement,  and  find  a  principal  type  for  or  (not  x,  x) 
in  the  resulting  environment.  Then  we  would  encode  the  results  as  an  intersection  of  arrow 
types;  for  example,  if  assuming  x  has  the  type  ff  leads  to  the  conclusion  or  (not  x ,  x) 
has  the  type  it,  then  one  of  the  components  of  the  result  is  ff  — *  tt. 

Modifying  this  procedure  to  enforce  our  invariant  is  fairly  simple.  Instead  of  binding  x 
to  a  type  r  in  the  environment,  find  a  principal  split  of  r.  Bind  x  to  each  fragment  of  r  and 
find  a  principal  type  for  or  (not  x,  x)  in  the  resulting  environment.  Let  k  be  the  join  of 
the  results;  then  the  component  we  should  add  to  our  result  in  this  case  is  r  — ►  k. 

For  example,  when  we  consider  the  refinement  T /  of  bool,  we  find  its  principal  split 
{tt,ff}.  We  bind  x  to  each  of  the  fragments  and  find  types  for  or  (not  x,  x)  in  the  result¬ 
ing  environments,  yielding  It  and  tt.  Then  we  join  these,  yielding  tt.  The  final  contribution 
of  this  reasoning  to  our  result  is  — >  tt.  The  type  for  f  n  x :  bool  =>  or  (not  x ,  x) 

that  results  from  this  procedure  is 

T tow  ->  tt  A  tt  -» tt  A  ff  -*  ttA  J — ►  Itooi  ■ 


Applications  Applications  become  a  call  to  i  at  the  type  level.  For  example,  to  find 
a  principal  type  for  not  x,  first  we  find  principal  types  for  not  and  x;  suppose  we  get 
tt  — »  ff  A  ff  — » tt  A  T  iooi  — >  T iooi  and  tt,  respectively.  Then  our  result  is 

i{tt  -»  ff  A  ff-+tt  ATW-*  T*^)(tt), 


which  is  ff  A  T iool. 

Constructor  Applications  This  case  is  straightforward.  Using  the  bitstr  datatype  first 
introduced  on  page  17  as  an  example,  if  we  want  to  find  the  principal  type  of  an  expression 
like  One  (Empty  ()),  we  first  find  a  principal  type  for  Empty  (),  yielding  em.  Then  our 

def 

result  is  the  least  type  re  such  that  One  :  em  r— *  rc;  in  this  case  it  is  nf. 

By  Assumption  2.51  (Constructor  And  Introduction)  on  page  67,  the  least  rc  such  that 

One  df  em  <—*  rc  is  the  intersection  of  all  of  the  re’s  such  that  One  df  em  *-»  rc.  This 
intersection  can  be  precomputed  when  the  constructors  are  defined,  so  this  does  not  affect 
performance 

Case  Statements  Finding  the  principal  type  of  a  case  statement  starts  as  an  approximate 
dual  of  finding  a  principal  type  for  constructor  applications.  First  we  find  a  principal  type 
for  the  expression  the  case  statement  is  examining;  we  can  use  r  cons  imp  discussed  on 
page  42  to  simplify  this  type  to  something  of  the  form  rc.  For  each  branch  of  the  case 
statement  with  a  constructor  c  we  find  the  set  of  greatest  r’s  such  that  c  d'f  r  *-»  rc.  These 
r’s  are  the  possible  types  of  the  argument  to  c  that  could  have  given  rise  to  our  case  object. 
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The  analogy  with  constructor  application  is  only  approximate  because  we  cannot  join 
all  of  the  r’s  in  this  set  to  get  a  k  where  c  df  k  <— >  re;  in  other  words,  there  is  no  dual 
to  Assumption  2.51  (Constructor  And  Introduction)  on  page  67.  This  is  case  because  A 
accurately  forms  intersections  of  refinement  types  if  we  interpret  them  as  sets,  but  U  only 
returns  an  upper  bound  of  the  union. 

If  the  set  of  possible  r’s  for  some  constructor  is  empty,  then  that  branch  is  unreachable. 
Recall  that  in  the  formal  language,  a  branch  of  a  case  statement  is  a  function  that  will 
be  applied  to  the  arguments  of  the  constructor.  For  each  reachable  branch  e  of  the  case 
statement  we  find  a  principal  type  for  the  application  of  e  to  some  hypothetical  value  of 
type  r;  by  the  argument  we  gave  for  the  application  case,  this  is  simply  a  use  of  i.  Since 
we  do  not  know  which  of  the  reachable  cases  will  be  taken  during  execution,  we  have  to 
take  the  join  of  all  of  these  types  as  the  principal  type  of  the  case  statement. 

For  example,  consider  the  case  statement 

case  Zero  (One  (Empty  ()))  of 
Zero  ~>  f n  arg :  bitatr  =>  arg 
I  One  =>  fn  arg  :bitstr  =>  One  arg 
1  Empty  =>  fn  arg :runit  =>  (Empty  ()) 
end :  bitstr 

From  the  earlier  discussion  of  application,  the  principal  type  of  Zero  (One  Empty)  is  nf. 
The  reachable  constructors  are  Zero  and  One,  where  Zero  has  the  possible  input  type  nf 
and  One  has  the  possible  input  types  nf  or  em. 

The  best  type  for  fn  arg:  bitatr  =>  arg  applied  to  a  value  of  type  nf  is  nf,  and  the 
best  type  of  f  n  arg :  bitatr  =>  One  arg  applied  to  a  value  of  type  nf  or  em  is  nf.  Thus 
the  principal  type  of  the  case  statement  is  nf  U  nf,  or  nf. 

Tuples  The  principal  type  for  a  tuple  is  simply  the  product  of  the  principal  types  of 
the  components.  For  example,  to  find  the  principal  type  for  (not ,  true  ())  we  first  find 
the  principal  types  of  not  and  true  (),  yielding  tt-*ffAff^tt  AT  boot  — >  T  &„„/  and  tt 
respectively.  Thus  the  type  for  (not ,  true  ())  is 

{tt  —*  ff  A  ff  — y  tt  A  T igoi  — >  T jo,,/)  *  tt. 


Element  Selection  To  find  a  principal  type  of  an  expression  of  the  form  elt _rn_n  e, 
find  a  principal  type  for  e,  simplify  it  with  tuple  simp,  and  then  select  the  appropri¬ 
ate  element.  For  example,  a  principal  type  for  (true  (),  false  ())  is  {tt  *  T 4op/)  A 
(T boot  *  ff).  Then  tuplesirap  returns  {tt  A  T j00j)  *  (T 4 ool  A  ff),  so  a  principal  type  for 
elt_2_2  (true  () ,  false  ())  is  T  4oo/  A  ff,  which  is  equivalent  to  ff. 

Fixed  Points  We  find  the  principal  type  for  a  fixed  point  by  iterative  approximation.  Our 
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first  approximation  to  the  refinement  type  of  the  function  is  the  least  refinement  of  its  ML 
type;  each  successive  approximation  is  the  principal  type  of  the  body  of  the  fixed  point, 
assuming  that  recursive  references  to  the  function  have  the  previous  approximation  as  their 
type.  When  the  approximations  stop  increasing,  the  last  approximation  is  our  principal 
type. 

For  example,  determining  a  type  for  the  expression 

fix  inc :  bitstr —*  bitstr  =>  fn  n  :  bitstr  => 
case  n  of 

Empty  =>  fn  _:runit  =>  One  (Empty  ()) 

I  One  =>  fn  rest :  bitstr  ->  Zero  (inc  rest) 

I  Zero  =>  fn  rest :  bitstr  =>  One  rest 
end:  bitstr 

yields  these  successive  approximations  to  the  fixed  point: 

T iitttr  >  -L  bitstr 

■L  bitstr  *  JL  bitstr  A  CTTl  >  Tlf  A  Tlf  >  Tlf  A  T  bitstr  ►  T  bitstr 
-1-  bitstr  — *  -1-  bitstr  A  tm  —*  Tlf  A  Tlf  —*  Tlf  AT  bitstr  T  bitstr- 

Since  the  last  two  approximations  are  equivalent,  the  process  terminates  and  the  last  ap¬ 
proximation  is  our  result. 


2.10.4.2  Technical  Lemma  for  Principality 

To  show  that  the  types  from  infer  are  principal,  we  will  have  to  prove 

if  VR  h  e  :  r  then  (infer  VR  e)  <  r. 

The  premise  VR  h  e  :  r  is  awkward  to  use  because  the  root  inference  of  its  derivation  may 
be  an  inference  rule  that  makes  syntactic  progress,  or  it  may  be  WEAKEN-TYPE,  and- lntro- 
TYPE,  or  SPLIT-TYPE.  It  turns  out  that  it  is  sufficient  to  show 

if  VR  H-  e  :  r  then  (infer  VR  e)  <  r 

where  the  root  inference  of  the  premise  must  make  syntactic  progress.  The  SPLIT-TYPE  case 
of  the  proof  is  most  interesting. 

Lemma  2.98  (Syntactic  Progress  Decidability  Sufficient)  Let  r'  be  given.  If 

for  all  r  we  have  VR  H-  e  :  r  implies  r'  <r 


and 


VR  I-  e  :  p 
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and  for  all  x  in  the  domain  o/VR  we  have 


all  splits  ofW R(x)  are  useless 


r'  <  p. 


Proof:  By  induction  on  the  derivation  of  VR  I -  e  :  p.  The  proof  is  relatively  short  because 
we  can  trivially  handle  the  cases  where  the  root  inference  of  this  derivation  makes  syntactic 
progress. 

Case:  AND-INTRO-TYPE  The  p  has  the  form  p\  Ap2  where  the  premises  of  and- intro-type 
are 

VRherp, 

and 

VR  h  e  :  P2- 

Two  uses  of  the  induction  hypothesis  give 

r'  <  p, 


Then  AND-INTRO-SUB  gives 


which  is  our  conclusion. 


r'  <P2. 


r'  <  pi  A  P2, 


Case:  weaken-type  Then  the  premises  of  weaken-type  are 

VR  1-  e  :  p' 


By  induction  hypothesis. 


SO  TRANS-SUB  gives 


which  is  our  conclusion. 


p'  <  p. 


r'  <  p', 


r'  <  p 


Case:  SPLIT-TYPE  Then  VR  has  the  form  VR'[y  :=  k)  where  the  premises  of  split-type 


k  x  a 
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and 

for  k'  in  s  we  have  WR'[y  :=  &']  b  e  :  p. 

By  hypothesis,  a  is  a  useless  split  of  k ,  so  we  can  choose  a  k'  in  s  such  that  k  =  k'. 

We  will  be  putting  k'  in  an  environment  and  then  using  the  induction  hypothesis, 
need  to  know  that  all  splits  of  k!  are  useless.  To  show  this,  suppose  that  k'  x  s'. 
EQUIV-SPLIT-L  gives  k  x  s',  and  by  hypothesis  there  is  therefore  a  k"  in  s'  such  that  k 
Trans-sub  then  gives  k'  =  k".  Thus, 

all  splits  of  k'  are  useless. 


Now  we  have  to  take  cases  on  the  form  of  e  to  show  that 

VR'[y  :=  k']  H-  e  :  r  implies  r'  <  r. 

The  most  interesting  of  the  following  cases  is  when  e  is  some  variable  other  than  y. 

Suppose  that 


SubCase:  e  is  not  a  variable 


WR'[y  :=  k'}  H-  e  :  r. 

Lemma  2.66  (Environment  Modification)  on  page  81  gives 

VR'[y  :=  &]H-  e  :  r 


and  our  hypothesis  gives 


r'  <  r. 


Summarizing,  the  reasoning  so  far  in  this  subcase  gives 


VR#[y  :=  fc']  H-  e  :  r  implies  r'  <  r. 


SubCase:  e  has  the  form  y  Suppose 


VR'[y  :=  k'}  H-  y  :  r. 

The  last  inference  of  this  must  be  var-type,  so  r  =  k'.  Var-type  gives 

VR'[y  :=  k\  H-y  :  k, 

so  our  hypothesis  gives 

r'  <  k. 

Since  k  =  k1,  this  implies  r'  <  r.  Summarizing  the  steps  in  this  subcase  so  far, 


so  we 
Then 
=  k". 


VR'[y  :=  fc']  H-  y  :  r  implies  r'  <r. 
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SubCase:  e  has  the  form  z,  where  z  ^  y 


Suppose 


VR'[y  :=  ft*]  H-  z  :  r. 
Since  z  ^  y,  this  derivation  ignores  y,  so  we  also  have 

VR'[y  :=  ft]  H-  z  :  r. 


By  hypothesis,  this  implies 


r  <  r. 


Summarizing  the  steps  in  this  subcase  so  far, 

VR'[y  :=  k'\  H-  z  :  r  implies  r'  <  r. 


Regardless  of  which  subcase  we  use,  one  of  the  premises  of  SPLIT-TYPE  is 

VR'[y  :=  ft']  he:  p. 

We  can  use  the  induction  hypothesis  on  this  and  the  result  from  whichever  subcase  we  used 
to  get 

r'<P, 

which  is  our  conclusion. 


Case:  Any  rule  that  makes  syntactic  progress 


In  that  case  we  have 


so  our  hypothesis  gives 
•  which  is  our  conclusion. 


VRH-e:p 


r'<P , 


□ 


2.10.43  Definition  and  Proof  of  Refinement  Type  Inference  Algorithm 

The  decision  procedure  for  monomorphic  refinement  types  is  in  Figures  2.7  and  2.8.  This 
procedure  takes  an  expression  and  an  environment  mapping  variables  to  refinement  types, 
and  it  returns  a  principal  refinement  type  for  the  expression  if  there  is  one,  or  ns  otherwise. 
It  has  three  interesting  properties:  it  always  terminates,  it  returns  a  refinement  type  for 
the  given  expression,  and  the  type  is  principal.  We  will  prove  one  of  these  properties  in 
each  of  the  next  three  theorems.  The  most  interesting  theorem  in  this  Subsubsection  is 
Theorem  2.101  (Infer  Returns  Principal  Type)  on  page  151;  the  most  interesting  cases  of 
each  theorem  (teal  with  case  and  fix  statements. 

The  portions  of  the  algorithm  that  deal  with  case  and  fix  statements  use  the  “as” 
keyword.  This  has  not  appeared  so  far  in  this  thesis.  It  simultaneously  binds  a  variable 
to  a  structure  and  other  variables  to  the  parts  of  the  structure;  for  example,  binding  the 
pattern  x  as  (y,  z)  to  the  value  (true,  false)  binds  y  to  true,  z  to  false,  and  x  to 
(true,  false). 
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fun  infer  VR  y  = 

if  for  some  t  we  have  VR(y)  C  t 
then  VR(y) 
else  ns 

I  infer  VR  (fn  x:t  =>  e')  * 

if  there  is  a  tt  such  that  rtom(VR)[x  :=  f] 
then 

let  val  tt  -  the  unique  tt  such  that  rtom(VR)[*  :=  t]  h  e' ::  tt 
fun  do _ one  r  - 

sjoinf  it  {infer  (VR[x  :=  r'])  e'  |  r'  £  split  r} 
in 

Afn  {r— >do_one  r  \  r  €  allrefs  t  and  (do_one  r)  ^  ns} 

end 
else  ns 

I  infer  VR  (et  e2)  = 

let  val  r?  =  infer  VR  e\ 
val  fc?  =  infer  VR  e2 
in 

if  r?  *  ns  or  kl  =  ns 
then  ns 
else 
let 

val  tt  — *  t  =  rtom(r?) 
val  u'  =  rtom(fc?) 
in 

if  tt  ■  tt' 
then  ifn  r?  &?  tt 
else  ns 

end 

end 

I  infer  VR  (c  e')  = 

let  val  kl  =  infer  VR  e' 

val  t  =  the  unique  t  such  that  c  ::  t^tc 
in 

Afn  {nc  |  r  6  allrefs  t  and  subtypep  kl  r  t  and  c  :  r  <— ►  rc} 

end 

Figure  2.7:  Decision  Procedure  for  Refinement  Types  Part  1 
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I  infer  VR  (e  as  (case  eo  of  c\  *>  et  I  ...  I  Cn  *>  en  end:*))  = 
if  not  rtom(VR)  he::*  then  ns 
else  let  val  r?  =  infer  VR  eo 
in  if  r?  =  ns  then  ns 

else  let  val  rc  =  r  cons  imp  (r?) 
in 

sjoinf  t  {ifn  (infer  VR  e*)  p  u  j 
h  (E  l..n 

def 

and  ch  ::  u <— *■  uc 

and  p  G  allref  s  u 

.  def  1 

and  Ch  :  p  *— ►  re} 

end 

end 

I  infer  VR  (et,  ....  e„)  * 

if  for  any  i  in  l..n  we  have  infer  VR  e*  *  ns 
then  ns 

else  infer  VR  e\  *  ...  *  infer  VR  en 
I  infer  VR  (elt_m_n  e')  = 

let  val  fc?  =  infer  VR  e' 
in 

if  fc?  a  ns  then  ns 

else  let  val  k\  *  ...  *  kn  =  tuplesimp  (A:?) 
in  km  end 

end 

I  infer  VR  (e  as  (fix  f:t  =>  fn  x:t\  =>  e'))  = 
let  fun  loop  r  = 

let  val  nextl  -  infer  (VR[/ :=  r])  (fn  x:t\  =>  e') 
in 

if  subtypep  nextl  r  t  then  r 
else  if  nextl  =  ns  then  ns 
else  loop  nextl 
end 

val  t\  — >  *2  =  t 
in 

if  t\  ^  t\  then  ns 

else  if  ML  type  inference  does  not  give  rtom(VR)  I-  e  ::  *i  — » t2 
then  ns 

else  loop  (botfn  (*i  — » *2)) 

end 

Figure  2.8:  Decision  Procedure  for  Refinement  Types  Part  2 
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According  to  Theorem  2.54  (Inferred  Types  Refine)  on  page  68,  the  refinement  type 
inference  rules  in  Figure  2.6  ensure  that  the  refinement  type  environment  gives  a  well- 
formed  refinement  type  for  each  free  variable  in  the  expression  and  that  the  expression 
has  an  ML  type.  Since  infer  is  an  implementation  of  these  rules,  it  does  the  same.  The 
alternative  would  be  to  assume  we  only  use  infer  on  terms  and  environments  that  are 
consistent  with  ML  typing.  The  extra  hypothesis  would  complicate  the  proofs  and  obscure 
the  correspondence  between  the  refinement  type  inference  rules  and  the  algorithm,  so  the 
approach  used  below  seems  best. 

The  algorithm  has  an  invariant:  the  refinement  types  in  the  environment  must  have  no 
useful  splits.  Because  of  this  assumption,  we  never  need  to  consider  using  the  SPLIT-TYPE 
rule  to  split  variables  that  are  in  the  initial  environment.  As  we  execute  the  algorithm,  we 
maintain  the  invariant  by  taking  the  principal  split  of  the  type  of  each  new  variable  before  we 
add  it  to  the  environment.  The  discussion  of  principal  splits  above  should  make  it  intuitively 
clear  that  this  is  appropriate;  for  a  formal  justification,  see  the  cases  for  abstractions  and 
fixed  points  in  the  proof  of  Theorem  2.101  (Infer  Returns  Principal  Type)  on  page  151. 

We  start  with  a  simple  lemma  saying  that  the  argument  of  the  tail  recursive  loop  in 
the  fix  case  of  infer  always  refines  the  same  ML  type.  The  hypothesis  of  the  lemma  is 
always  true  since  it  is  implied  by  Theorem  2.100  (Infer  Returns  Some  Type)  on  page  145; 
the  hypothesis  saves  us  from  having  a  lemma  nested  inside  a  theorem.  Note  that  the 
variables  t{  and  t2  mentioned  in  the  lemma  are  defined  in  the  fix  case  of  infer. 


Lemma  2.99  (Fix  Case  of  Infer  is  Well-Behaved)  In  the  fix  case  of  infer,  we  will  ab¬ 
breviate  f n  x:t\  =>  e'  as  e".  If,  for  all  r. 


infer  (VR[/  :=  r])  e"  is  not  ns 

implies 

VR [/  :=  r]  h  e"  :  infer  (VR[/  :=  rj)  e", 
then  the  argument  of  loop  always  refines  t\—*t2. 


Proof:  By  induction  on  the  evaluation  loop. 


Case:  Initial  call  to  loop 


This  is  trivial,  since  the  argument  to  the  initial  call  of  loop  is 


botfn  ($i  —*  t2),  which  obviously  refines  f i  — >  t2. 


Case:  Recursive  calls  to  loop  |  We  can  assume  the  incoming  argument  r  of  loop  refines 

1 1  —i ►  t2,  and  we  need  to  show  that  the  value  next?  that  will  be  passed  to  the  next  recursive  call 
also  refines  t\  ~^t2.  Since  next?  =  infer  (VR[/  :=  r])  (in  x:t\  =>  e'),  our  hypothesis 
gives 

VR[/  :=r]he”:  next ?. 

Theorem  2.54  (Inferred  Types  Refine)  on  page  68  then  gives  a  t '  such  that  next?  (Z  t'  and 

rtom(VR(/  :=  r])  H  e"  ::  i'. 
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Since  r  C  tj  — ►  t2, 

rtom(VR[/  :=  r])  =  rtom(VR)[/  :=  ti  — ♦  <2]- 
If  we  ever  call  loop  then  t  must  have  the  form  t\  — *■  t2,  and  we  must  also  have 

rtom(VR)  t-  e  ::  t\  — »  t2. 

The  last  inference  of  this  must  be  Fix- valid  with  the  premise 

rtom(VR)[/  :=£,->  t2 }  b  e"  ::  t,  -> t2 

Thus  Lemma  2.4  (Unique  Inferred  ML  Types)  on  page  27  gives  t'  =  t\~*  t2.  Since 
next ?  C  £',  this  is  our  conclusion.  D 

In  the  next  theorem  we  have  the  hypothesis  “infer  VR  e  terminates”.  By  Theorem 
2.102  (Infer  Terminates)  on  page  160,  this  is  always  true.  Once  again  we  are  using  these 
always  true  hypotheses  to  break  up  the  decidability  proof  into  manageable  chunks. 

Theorem  2.100  (Infer  Returns  Some  Type) 

//infer  VR  e  terminates  and  infer  VR  e  is  not  ns  then 

VR  b  e  :  infer  VR  e. 


Proof:  By  induction  on  e. 


Case:  e  =  y 


The  code  for  this  case  is 


fun  infer  VR  y  - 

if  for  some  t  we  have  VR(y)  C  t 
then  VR(y) 
else  ns 


Since  infer  VR  e  is  not  ns,  it  is  VR(e)  and  for  some  t  we  have  VR(e)  C  t.  Thus 
VAR-TYPE  gives  VR  b  e  :  infer  VR  e,  which  is  our  conclusion. 


Case:  e  =  fn  x :  t  =>  e' 


The  code  for  this  case  is 


I  infer  VR  (fn  x:t  =>  e')  = 

if  there  is  a  u  such  that  rtom(VR)[s  :=  t ]  he'::u 

then 

let  val  u  -  the  unique  u  such  that  rtom(VR)[r  :=  £]  b  e' ::  u 
fun  do_one  r  = 

sjoinf  u  {infer  (VR[x  :=  r'])  e'  |  r'  €  split  r} 
in 

Afn  {r-*do_one  r  |  r  G  allrefs  t  and  (do.one  r)  ^  ns} 

end 
else  ns 
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Since  infer  VR  e  is  not  ns,  there  is  a  u  such  that  rtom(VR)  h  e'  ::  u.  By  Lemma  2.4 
(Unique  Inferred  ML  Types)  on  page  27,  there  is  exactly  one  such  u. 

Since  infar  VR  e  terminates,  soundness  of  Afn  tells  us  that  all  calls  to  do_ona 
terminate.  Since  infer  VR  e  is  not  ns,  at  least  one  of  the  calls  to  do.one  returns  a 
refinement  type  instead  of  ns.  Suppose  do_one  r  does  not  return  ns;  by  definition  of 
do.ona,  this  implies 

for  all  r'  in  split  r  we  have  infer  (VR[x  :=  r'])  e'  terminates  and  is  not  ns. 

We  can  use  our  induction  hypothesis  to  get 

for  all  r'  in  split  r  we  have  VR[x  :=  r']  f-  e' :  infer  (VR[x  :=  r'j)  e' 

By  WEAKEN-TYPE  and  soundness  of  s  jo  inf ,  we  get 

for  all  r'  in  split  r  we  have  VR[x  :=  r']  h  e' :  do.one  r. 

Soundness  of  split  tells  us  r  >:  split  r.  Thus  SPLIT-TYPE  gives 

VR[x  :=  r]  h  e' :  do_one  r. 

Then  abs-type  gives 

VR  f-  f  n  x :  t  ->  e' :  r  — ►  do_one  r. 

This  is  true  for  all  r  refining  t  for  which  do_one  r  is  not  ns,  so  repeated  use  of  and-intro- 
TYPE  gives 

VR  h  fn  x:t  *>  e' :  infer  VR  e, 

which  is  our  conclusion. 

Case:  e  =  e\  e2  The  code  for  this  case  is 

I  infer  VR  (ej  e2)  - 

let  val  r?  ■  infer  VR  e\ 
val  kl  =  infer  VR  e2 
in 

if  r?  =  ns  or  kl  -  ns 
then  ns 
else 
let 

val  u—*t  =  rtom(r?) 
val  u'  =  rtom(&?) 
in 

if  u  -  u' 
then  ifn  r?  kl  u 

else  ns 

end 

end 
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Since  infer  VR  e  is  not  ns,  both  r?  and  A?  must  not  be  ns.  Call  them  r  and  k  respectively. 
Since  r  =  infer  VR  t\  and  k  =  infer  VR  e2,  the  induction  hypothesis  gives 

VR  h  e,  :  r 


and 


VR  b  e2  :  k. 


Since  rCu-*i,  we  know  that  r  has  the  form  rt  -> A  . . .  A  rn  — » r'n.  By  soundness 
of  ifn, 

ifn  r  k  u  =  A{r^  |  j  £  1 . .  .n  and  k  <  r^}. 

Since  VR  h  e2  :  k,  WEAKEN-TYPE  gives 

for  j  in  1 . . .  n  such  that  k  <  rj  we  have  VR  1-  e2  :  Tj. 

Since  VR  b  e\  :  r,  we  can  use  WEAKEN-TYPE  to  get 

for  all  j  in  1 ...  n  we  have  VR  b  t\  :  r,  — » r' . 

Therefore  APPL-TYPE  gives 

for  j  in  1 . . .  n  such  that  k  <  Tj  we  have  VR  he!  e2  :  r' 
and  repeated  use  of  and-intro-TYPE  gives 


VR  h  ei  e2  :  ifn  r  k  u. 
By  definition  of  this  case  of  inf  or,  this  is  our  conclusion. 
The  code  for  this  case  is 


Case:  e  =  c  e' 


I  infer  VR  (c  e')  = 

let  val  k ?  =  infer  VR  e' 

dcf 

val  t  -  the  unique  t  such  that  c  ::  t<-+tc 
in 

Afn  {nc  |  r  £  allref s  t  and  subtypep  fe?  r  t  and  c  :  r  t-*  nc} 

end 

Since  infer  VR  e  is  not  ns,  soundness  of  Afn  and  subtypep  tell  us  that  k?  cannot  be 
ns.  Thus  we  will  call  it  k.  The  value  of  infer  VR  e  must  have  the  form 

rc i  A  ...  A  rcn 

where  for  i  in  1 ... »  we  have  an  r,-  refining  t  such  that  c  d-!f  Vi  <—*  rci  and  k  <  r;.  By 
induction  hypothesis, 


VR  b  e' :  k, 
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and  by  weaken-type. 


for  i  in  1 ...  n  we  have  VR  H  e' :  rj. 


Then  constr-type  gives 


for  i  in  1 ...  n  we  have  VR  He  e' :  rc* 
and  repeated  use  of  and- intro-type  gives 

VR  He  :  rcj  A  . . .  A  rcn, 


which  is  our  conclusion. 


Case:  e  —  case  e0  of  c\  a>  e\  I  ...  I  Cn  =>  en  end:f 


The  code  for  this  case  is 


Cn  *>  e„  end:*)) 


infer  VR  (e  as  (case  eo  of  ci  =>  e\  I  . . 
if  not  rtom(VR)  H  e  ::  t  then  ns 
else  let  val  r?  =  infer  VR  eo 
in  if  r?  =  ns  then  ns 

else  let  val  rc  -  r  cons  imp  (r?) 
in 

sjoinf  t  {ifn  (infer  VR  e/,)  p  u 


h  €  l..n 

.  def 

and  cn  ::  u  «- 


uc 


and  p  €  allref  s  u 
rc} 


,  def 

and  Ch.  :  p 


end 


end 


Let  fc  be  the  result  of  this  case  of  infer.  By  hypothesis  this  case  does  not  return  ns,  so 
infer  VR  eo  is  defined.  Our  induction  hypothesis,  soundness  of  rconsimp,  and  weaken- 
type  give 

VR  H  eo  :  rc. 

Let  h  in  1 . . .  n,  u,  and  p'  C  u  be  given  such  that 


def  > 

Ch  :  P  * ►  rc. 


(2.60) 


By  soundness  of  allref  s,  there  is  a  p  in  allref  s  u  such  that  p  =  p',  and  Assumption 
2.52  (Constructor  Argument  Strengthen)  on  page  67  gives 

def 

Ch  ■  p’—*rc. 


Then,  by  soundness  of  sjoinf,  we  have 


ifn  (infer  VR  e\)  p  u  <  k. 
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By  soundness  of  ifn  and  Lemma  2.83  (t  Gives  an  Upper  Bound)  on  page  111,  this  implies 

infer  VR  e*  <  p  — >  A. 

By  induction  hypothesis, 

VR  I-  en  :  infer  VR  e^, 

and  then  weaken-type  gives 

VR  b  :  p  — >  fc. 

Since  p  =  p',  we  have  p-+k  =  p'-*k,  so  using  weaken-type  again  gives 

VR  b  eA  :  p'  — A. 

Summarizing  the  argument  from  (2.60)  to  here, 

for  all  h  in  1 . . .  n, 

del  . 

Ch  :  p  <— ♦  rc 
implies 

VR  b  eh  :  p'  — *  k. 

The  algorithm  explicitly  ensures  that 

rtom(VR)  b  e  ::t. 

Since  sjoinf  t  s  always  returns  a  refinement  of  t. 


Thus  we  can  use  case-type  to  get 


which  is  our  conclusion. 


kCt. 


VR  b  e  :  k, 


Case:  e  =  (ei ,  ...»  en)  The  code  for  this  case  is 


infer  VR  (e! ,  ...,  en)  = 

if  for  any  i  in  l..n  we  have  infer  VR  e*  =  ns 
then  ns 

else  infer  VR  ei  *  ...  *  infer  VR  en 


Since  infer  VR  e  is  not  ns,  for  h  in  1  ...n  we  have  infer  VR  is  not  ns.  By  induction 
hypothesis,  this  implies 

for  h  in  1 ...  n  we  have  VR  b  eh  :  infer  VR  eh 
and  then  tuple-type  gives 

VR  b  (ej . en)  :  infer  VR  e\  *  . . .  *  infer  VR  en 

which  is  our  conclusion. 

Case:  e  =  elt  _m_n  e'  The  code  for  this  case  is 
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!  infer  VR  (elt_m_n  e')  3 

let  val  k ?  3  infer  VR  e' 
in 

if  k?  3  ns  then  ns 

else  let  val  k\  *  . . .  *  kn  -  tuplesimp  ( k ?) 
in  km  end 

end 


Since  infer  VR  e  is  not  ns,  infer  VR  e'  must  not  be  ns;  call  it  k.  By  induction 
hypothesis  we  must  have 

VRhe':  k. 


By  soundness  of  tuplesimp,  k\*. .  .*kn  =  k,  and  by  WEAKEN-TYPE,  VR  b  e' :  k\*...*kn. 
Then  ELT-TYPE  gives  VR  b  elt _m_n  e' :  km,  which  is  our  conclusion. 


Case:  e  =  f ix  fit  *>  fn  xit\  *>  e' 


The  code  for  this  case  is 


I  infer  VR  (e  as  (fix  fit  3>  fn  xit\  =>  e'))  3 
let  fun  loop  r  3 

let  val  next ?  3  infer  (VR[/  :=  r])  (fn  x:f]  =>  e') 
in 

if  subtypep  next?  r  t  then  r 
else  if  next ?  3  ns  then  ns 
else  loop  next ? 
end 

val  t  j  —*tn  =  t 
in 

if  t'j  7^  £i  then  ns 

else  if  ML  type  inference  does  not  give  rtom(VR)  b  e  ::  fi  — *  t-i 
then  ns 

else  loop  (botfn  (fi  — »•  ^2)) 

end 

We  will  abbreviate  fn  x:*i  =>  e'ase"  Suppose  infer  VR  e  returns  r.  The  definition 
of  loop  tells  us  that  next?  ■<  r  where 

next?  =  infer  (VR[/  :=  r])  e". 

Our  induction  hypothesis  gives 


VR[/  :=  r]  b  e"  :  next ? 
and  WEAKEN-TYPE  used  with  next?  -<  r  gives 


VR(/  :=  r]  b  e"  :  r. 
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Lemma  2.99  (Fix  Case  of  Infer  is  Well-Behaved)  on  page  144  gives  r  o  1 1  — »  ti,  so  fix-type 
gives 

VR  H  fix  =>  e"  :r 


which  is  our  conclusion.  a 

The  next  theorem  shows  that  when  infer  returns  a  refinement  type,  it  returns  a  principal 
refinement  type.  One  of  the  hypotheses  is  that  infer  terminates  on  its  input.  Theorem 
2.102  (Infer  Terminates)  on  page  160  tells  us  this  is  always  true,  but  we  have  to  have  an 
explicit  hypothesis  here  because  we  have  not  yet  proved  that  theorem.  An  alternative  would 
be  to  prove  both  theorems  at  once;  that  would  lead  to  one  large  proof  instead  of  two  smaller 
ones. 


Theorem  2.101  (Infer  Returns  Principal  Type)  If 


and 


then 


all  splits  of  types  in  VR  are  useless 


infer  VR  e  terminates 

if  there  is  an  r  such  that  VR  (~  e  :  r  then 
(infer  VR  e)  X  r. 


Proof:  By  induction  on  e.  But  first  we  need  to  derive  the  simple  consequence  of  Lemma 
2.98  (Syntactic  Progress  Decidability  Sufficient)  on  page  138  that  we  will  use  to  prove 
principality: 


Suppose 


VR  H-  e  :  r  implies 

(infer  VR  e)  ^  r. 


(2.61) 


Also  suppose 


VR  I ~  e  :r. 


(2.62) 


Clearly  any  derivation  of  (2.62)  is  going  to  include  a  derivation  of  VR  H-  e  :  r’  for  some  r\ 
Therefore,  (2.61)  gives 

infer  VR  e  is  not  ns  (2.63) 

and  Lemma  2.98  (Syntactic  Progress  Decidability  Sufficient)  on  page  138  gives 


(infer  VR  e)  <  r. 


(2.64) 
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Thus  (2.62)  implies  (2.63)  and  (2.64),  which  is  our  principality  result.  The  reasoning  so  far 
tells  us  that  (2.61)  implies  principality: 


For  all  r, 

(VR  If-  e  :  r  implies 

(infer  VR  e)  X  r) 

implies  (2.65) 

For  all  r, 

(VR  h  e  :  r  implies 

(infer  VR  e)  X  r) 


In  each  case  of  the  proof  below,  we  shall  use  (2.65)  to  establish  principality  instead  of  doing 
it  directly. 


Case:  e  =  y 


The  code  for  this  case  is 


fun  infer  VR  y  = 

if  for  some  t  we  have  VR(y)  C  t 
then  VR(y) 
else  ns 


Suppose  VR  H-  y  :  r.  Then  the  last  inference  of  this  must  be  VAR-TYPE  with  the  premises 
VR(y)  =  r  and  r  C  t.  Since  VR(y)  C  f,  we  know  that  infer  VR  y  returns  VR(y).  By 
SELF-SUB,  this  implies  (infer  VR  e)  <  r,  which  in  turn  implies  (infer  VR  e)  X  r. 
Thus  (2.65)  gives  principality. 


Case:  e  =  f n  x:t  =>  e' 


The  code  for  this  case  is 


I  infer  VR  (fn  x:t  =>  e')  3 

if  there  is  a  u  such  that  rtom(VR)[®  :=  f]  f-  e' ::  u 
then 

let  val  u  =  the  unique  u  such  that  rtom(VR)[®  :=  t]  \-  e' ::  u 
fun  do_one  r  = 

sjoinf  u  {infer  (VR[®  :=  r'])  e'  \  r'  £  split  r} 
in 

Afn  {r-*do_one  r  |  r  E  allrefs  t  and  (do_one  r)  ^  ns} 

end 
else  ns 


Suppose 


VRH-(fn  x:t  =>  e') :  p. 


The  last  inference  of  this  must  be  abs-type,  where  p  has  the  form  k" 
of  abs-type  are 


k'  and  the  premises 


k"ct 
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and 


VR[x  :=  A"]  H  e' :  k'. 

By  soundness  of  allrefs,  there  is  a  k  in  allrefs  t  such  that  k  =  k".  Suppose  r'  is 
in  split  k.  Then  r*  <  k,  so  r'  <  k"  and  Lemma  2.66  (Environment  Modification)  on 
page  81  gives 


\R[x  :=  r']  h  e' :  k' . 

Because  split  is  sound,  r'  has  no  useful  splits.  Thus  we  can  use  our  induction  hypothesis 
to  get 


(infer  (VR[x  :=  r'])  e')  ■<  k'. 
Because  sjoinf  is  sound  and  U  is  a  least  upper  bound, 

do.one  k  ■<  k' . 


Thus  ARROW-SUB  gives 


k  — * do_one  k  <  k—>k'. 
Since  k  =  k",  we  can  use  trans-SUB  and  RCON-SUB  to  get 

k  — >  do.one  k  <  k"  —*  k' . 


Thus  the  definition  of  infer  and  repeated  use  of  AND-ELIM-L-SUB  and  and-elim-r-sub 
give 

(infer  VR  e)  <  k"  —>  fc'. 

Summarizing  the  argument  so  far  in  this  subcase, 


VR  H-  f  n  x :  t  =>  e' :  p  implies 
(infer  VR  e)  -<  p. 


By  (2.65),  this  implies  our  conclusion. 


Case:  e  =  ei  e2 


The  code  for  this  case  is 
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I  infer  VR  (*i  e2)  * 

let  val  r?  =  infer  VR  e\ 
val  fc?  a  infer  VR  e 2 
in 

if  r?  *  ns  or  &?  *  ns 
then  ns 
else 
let 

val  u— *t  »  rtom (r?) 
val  u'  =  rtom(fc?) 
in 

if  u  =  u' 
then  ifn  r?  fc?  u 
else  ns 

end 

end 

Suppose  VR  H-  ei  e2  :  p'.  The  only  way  to  infer  this  is  with  APPL-TYPE  with  the  premises 

VR  t-  ei  :  p— >p' 


and 

VR  h  e2  :  p. 

Since  infer  VR  e  terminates,  both  infer  VR  et  and  infer  VR  e2  must  terminate. 
Thus  we  can  use  the  induction  hypothesis  on  each  of  these  to  get 

infer  VR  e\  ^p—*p' 


and 

infer  VR  e2  ^  p. 

Abbreviate  infer  VR  e\  as  r  and  infer  VR  e2  as  k. 

Uninteresting  reasoning  about  refinement  types  tells  us  that  rtom(r)  will  indeed  have 
the  form  u—>t  and  that  rtom(fc)  =  u. 

By  definition  of  *  we  have  t(p— >p')(p)  =  p'.  Lemma  2.81  (*  Monotone  in  First 
Argument)  on  page  109  implies  t(r)(p)  ■<  i(p— >p')(p),  and  Lemma  2.80  (i  Monotone  in 
Second  Argument)  on  page  108  implies  i{r)(k)  ■<  t(r)(p).  Thus 

*(r)(^)  r<  p' •  (2.66) 

Thus  infer  VR  e  is  not  ns.  We  can  use  the  definition  of  infer  to  rewrite  (2.66),  yielding 

infer  VR  e  •<  p'. 
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The  argument  in  this  subcase  so  far  can  be  summarized  as 

VR  H-  e\  C2  :  p'  implies 
infer  VR  c  X  p'. 

By  (2.65),  this  implies  our  conclusion. 


Case:  e  —  c  e' 


The  code  for  this  case  is 


I  infer  VR  (c  e')  = 

let  val  kl  *  infer  VR  e' 

val  t  =  the  unique  f  such  that  c  ::  f  <-*  tc 
in 

Afn  {nc  |  r  6  allref  s  £  and  subtypep  kl  r  t  and  c  :  r  <—*  re} 

end 


Suppose 


VR  H~  c  e' :  p. 

The  last  inference  of  this  must  be  CONSTR-TYPE,  where  p  has  the  form  pc  and  the  premises 


Of  CONSTR-TYPE  are 


def  , 

c  :  p  <—*  pc 


and 

VRhc':  p\ 

Our  induction  hypothesis  gives 

k ?  ^  p'. 


By  Assumption  2.2  (Constructors  have  Unique  ML  Types)  on  page  26,  there  are  unique  t 
and  tc  such  that  c  Is:  t  tc.  By  Assumption  2.49  (Constructor  Type  Refines)  on  page  65, 
p'  C  f,  so  there  is  an  r  in  allref  s  t  such  that  p'  =  r.  Then  Assumption  2.52  (Constructor 
Argument  Strengthen)  on  page  67  gives 


def 

c  :  r  pc 


and  trans-sub  gives 

fc?  x  r. 

Thus  pc  €  {re  |  r  6  allref  s  t  and  subtypep  kl  r  t  and  re}. 

Since  this  set  is  not  empty,  this  call  to  infer  does  not  return  ns.  By  repeated  use  of 
AND-ELIM-L-SUB  and  AND-ELIM-R-SUB, 

( A{re  |  r  6  allref  s  t  and  subtypep  kl  r  t  and  c  df  r  <— >  re})  <  pc. 


Summarizing  the  argument  so  far  in  this  subcase, 

VR  H-  e  :  p  implies 

(infer  VR  e)  ■<  p. 


156 


CHAPTER  2.  REFINEMENT  TYPE  INFERENCE 


By  (2.65),  this  implies  our  conclusion. 


Case:  e  =  case  e<)  of  Ci  =>  e\  I  ...  I  c„  =>  en  end :t 


The  code  for  this  case  is 


I  infer  VR  (e  as  (case  e0  of  c*  =>  ej  I  ...  1  Cn  =>  en  end:f))  = 
if  not  rtom(VR)  he::t  then  ns 
else  let  val  r?  =  infer  VR  eo 
in  if  r?  =■  ns  then  ns 

else  let  val  re  =  rconsimp  (r?) 
in 

sjoinf  t  {ifn  (infer  VR  e^)  p  u  \ 
h  G  l..n 

,  def 

and  Ch  ::  u  «— >  uc 

and  p  €  allrefs  u 

and  cn  :  p  ♦  rc} 

end 

end 


Suppose  we  have  an  r  such  that  VR  H-  e  :  r.  The  last  inference  of  this  must  be  CASE-TYPE 
with  the  premises 

VR  f-  eQ  :  kc, 


r  C.t, 

for  h  in  1 ...  n  and  all  k  such  that 

def  L.  L 

ch  :  k^kc  (2  67) 

we  have 

VR  H  en  :  k—*r, 


and 


rtom(VR)  H  e  ::  f. 


Thus  the  ML  type  checking  in  this  case  of  infer  succeeds  and  this  case  of  infer 
evaluates  infer  VR  e0.  Since  this  case  of  infer  terminates,  infer  VR  e0  must 
terminate.  Thus  our  induction  hypothesis  gives  (infer  VR  e0)  d  kc.  Let  rc  = 
rconsimp  (infer  VR  e0);  soundness  of  rconsimp  then  gives  rc  <  kc. 

Now  we  shall  show  that  for  all  h  in  1 . . .  n  and  all  p  such  that  c*  d?f  p  re. 


i( infer  VR  e*)(p)  <  r. 

First  choose  h  in  1 . . .  n  and  p  such  that  ch  d'f  p  *  re.  By  (2.67),  this  implies  VR  F  : 
p-*r.  Then  the  induction  hypothesis  gives 


infer  VR  e*  X  p  — » r. 
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By  Corollary  2.82  (Bound  on  Argument  to  t  Gives  Bound  on  t)  on  page  111,  this  implies 

i(infer  VR  Ch)(p)  <  r. 

dcf 

Since  this  holds  for  all  A  in  1 . . .  n  and  all  p  such  that  c*  :  p  <— *  re,  the  call  to  s  joinf  in 
this  case  of  infer  does  not  return  ns.  Thus 

infer  VR  e  is  not  ns 

and  s joinf  computes  a  least  upper  bound,  so 

(infer  VR  e)  ^  r. 


Summarizing  the  argument  so  far, 

VR  H-  e  :  r  implies 

(infer  VR  e)  X  r. 

By  (2.65),  this  implies  principality. 


Case:  e  =  (ej,  ...»  e„) 


The  code  for  this  case  is 


I  infer  VR  (et ,  ...»  en)  = 

if  for  any  tin  l..nwehave  infer  VR  =  ns 
then  ns 

else  infer  VR  et  *  ...  *  infer  VR  en 

Suppose  VR  H-(ei ,  . . . ,  en) :  r.  The  last  inference  of  this  must  be  tuple-type,  so  r  has. 
the  form  r\*...*rn  and  the  premises  of  TUPLE-TYPE  are 

for  h  in  1 ...  n  we  have  VR  b  e /, :  rh. 

Our  induction  hypothesis  gives 

for  h  in  1 ...  n  we  have  (infer  VR  eh)  ^ 

This  immediately  tells  us  that  infer  VR  e  is  not  ns.  RCON-SUB  gives 

infer  VR  e\  *  ...  *  infer  VR  en  <  r  *  rn 

and  by  definition  of  this  case  of  infer,  this  is  equivalent  to 

infer  VR  e  <  r. 

Summarizing  the  argument  so  far, 

VR  H-  e  :  r  implies 

(infer  VR  e)  X  r. 

By  (2.65),  this  implies  principality. 

Case:  e  =  elt _m_n  e' 


The  code  for  this  case  is 
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I  infer  VR  (elt_m_n  e')  = 

let  val  As?  *  infer  VR  e' 
in 

if  k?  *  ns  then  ns 

else  let  val  kx*...*kn  -  tuplesimp  (As?) 
in  km  end 

end 

Suppose  VRH-  elt  _m_n  e'  :  r.  The  last  inference  of  this  must  be  ELT-TYPE  with  the 
premise  VR  h  e' :  rt  *  . . .  *  rn  where  r  =  rm.  By  induction  hypothesis,  infer  VR  e'  is 
not  ns;  call  it  As.  The  induction  hypothesis  also  gives  k  <rx  *  ...*rn.  By  Theorem  2.21 
(Subtypes  Refine)  on  page  36,  there  must  be  a  t  such  that  As  (Z  t  and  rx  * . . .  *  rn  □  t.  We 
can  only  have  rx  *  . . .  *  rn  c  t  if  t  has  the  form  tx  *  ...  *tn.  Thus  As  is  a  valid  input  to 
tuplesimp,  and  soundness  of  tuplesimp  gives  k  —  tuplesinp  As. 

Let  kx*...*km  =  tuplesimp  As.  Then  TRANS-SUB  gives  kx*...*km  <rx*...*rn,  and 
Corollary  2.27  (TUPLE-SUB  Inversion)  on  page  45  gives  km  <  rm.  But  Kn  =  infer  VR  e 
and  rm  =  r,  so  we  have  (infer  VR  e)  <  r. 

Summarizing  the  argument  so  far, 

VR  H-  elt  _m_n  e' :  r  implies 
infer  VR  e  <  r. 


By  (2.65),  this  implies  principality. 


Case:  e  =  f ir  f:t  =>  fn  x:tx  =>  e' 


The  code  for  this  case  is 


1  infer  VR  (e  as  (fix  fit  =>  fn  x:tx  ->  e'))  * 
let  fun  loop  r  = 

let  val  next ?  *  infer  (VR[/ :=  r])  (fn  xitx  ->  e') 
in 

if  subtypep  next ?  r  t  then  r 
else  if  next ?  =  ns  then  ns 
else  loop  next ? 
end 

val  t\  — *■  $2  =  t 
in 

if  t\  /  then  ns 

else  if  ML  type  inference  does  not  give  rtom(VR)  h  e  ::  tx  — >  t2 
then  ns 

else  loop  (botfn  (f|  — *■  f2)) 

end 

We  will  abbreviate  fn  x:tx  ->  e'  as  e". 


2.10.  DECIDABILITY 


159 


For  the  base  case,  r  =  botfn  t.  Soundness  of  botf n  gives  r  <  k,  and  Lemma  2.66 
(Environment  Modification)  on  page  81  applied  to  (2.70)  gives  VR[/  :=  r]  h  e"  :  k.  By 
Fact  2.35  (Splits  of  Arrows  are  Simple)  on  page  51,  r  has  no  useful  splits;  thus  the  outer 
induction  hypothesis  tells  us  that  infer  (VR[/  :=  r])  e"  is  not  ns,  which  is  what  we 
wanted  to  show. 

For  the  induction  case,  this  call  to  loop  is  from  the  body  of  loop.  Thus  we  can  assume 
by  induction  that  r  <  k  and  we  have  to  show  that  next?  <  k  and  that  infer  (VR[/  := 
next?])  e"  is  not  ns.  Lemma  2.66  (Environment  Modification)  on  page  81  starting  with 
(2.70)  gives 

VR[/  :=  r]  h  e"  :  k. 

The  outer  induction  hypothesis  applies  because  Fact  2.35  (Splits  of  Arrows  are  Simple)  on 
page  5 1  tells  us  r  has  no  useful  splits,  so  we  have 

infer  (VR[/  :=  r])  e"  is  not  ns;  call  it  next? 

and 

next?  <  k.  (2.71) 

Lemma  2.66  (Environment  Modification)  on  page  81  starting  with  (2.70)  again  gives 

VR[/  :=  next?]  h  en  :  k 

and  the  outer  induction  hypothesis  (using  Fact  2.35  (Splits  of  Arrows  are  Simple)  on  page  5 1 
to  conclude  that  next?  has  no  useful  splits)  gives  infer  (VR[/  :=  next j)  e"  is  not  ns. 
This  and  (2.71)  are  our  conclusions.  This  completes  the  inner  induction. 


160 


CHAPTER  2.  REFINEMENT  TYPE  INFERENCE 


Now  we  have  everything  we  need  to  show  that  infer  VR  e  is  not  ns.  Theorem  2.54 
(Inferred  Types  Refine)  on  page  68  applied  to  (2.68)  gives  a  t'  such  that  k  c  t'  and 

rtom(VR)  H  e  ::  £'.  (2.72) 

Lemma  2.10  (Unique  ML  Types)  on  page  31  gives  t  =  t'.  By  (2.69)  and  (2.72),  the  if 
statements  before  the  initial  call  to  loop  do  not  cause  infer  to  return  ns.  By  the  most 
recent  induction,  the  call  to  loop  does  not  return  ns.  Thus 

infer  VR  e  is  not  ns. 

The  most  recent  induction  also  gives 

(infer  VR  e)  <  k. 

Summarizing  this  subcase  so  far, 

VR  H -  e:k  implies 

(infer  VR  e)  X  k. 


By  (2.65),  this  implies  principality.  □ 

The  next  theorem  shows  that  infer  always  terminates.  The  case  of  this  theorem  dealing 
with  fix  statements  uses  Theorem  2.101  (Infer  Returns  Principal  Type)  on  page  151. 

Theorem  2.102  (Infer  Terminates)  If 

all  splits  of  types  in  VR  are  useless 


then 


infer  VR  e  always  terminates. 


Proof:  By  induction  on  e.  The  cases  are  all  very  simple,  except  the  case  for  fix  statements. 


Case:  e  =  y 


The  code  for  this  case  is 


fun  infer  VR  y  = 

if  for  some  t  we  have  VR(y)  (Z  t 
then  VR(y) 
else  ns 


and  termination  is  trivial. 


Case:  e  =  f n  x:t  =>  e' 


The  code  for  this  case  is 
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I  infer  VR  (fn  x:t  •>  e')  ■ 

if  there  is  a  u  such  that  rtom(VR)[x  :=  t]  he'::u 

then 

let  val  u  =  the  unique  u  such  that  rtom(VR)[x  :=  i]  h  e' ::  u 
fun  do.one  r  * 

sjoinf  u  {infer  (VR[x  :=  r'])  e'  |  r'  €  split  r} 
in 

Afn  {r—* do.one  r  |  r  €  allrefs  t  and  (do_one  r)  ^  ns} 

end 
else  ns 


By  soundness  of  split,  all  r1  in  split  r  have  no  useful  splits.  Thus,  by  induction 
hypothesis,  the  recursive  calls  to  infer  all  terminate.  Since  principal  splits  are  computable, 
all  calls  to  split  terminate.  Since  the  refinements  of  an  ML  type  are  enumerable,  calls  to 
allrefs  terminate.  Thus  this  case  of  infer  terminates. 


Case:  e  =  e\ 


The  code  for  this  case  is 


I  infer  VR  (ei  ei)  - 

let  val  r?  =  infer  VR  ej 
val  kl  -  infer  VR  ti 
in 

if  r?  =  ns  or  fc?  =  ns 

then  ns 

else 

let 

val  u  — ►  t  =  rtom(r?) 
val  u'  =  rtom(fc?) 
in 

if  u  =  u' 
then  ifn  r?  kl  u 
else  ns 

end 

end 


By  induction  hypothesis,  the  recursive  calls  to  infer  terminate.  By  soundness  of  ifn  it 
always  terminates.  Thus  this  case  of  infer  terminates. 

Case:  e  =  c  e' 


The  code  for  this*  case  is 
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I  infer  VR  (c  e')  * 

let  val  k ?  *  infer  VR  e' 

val  t  ■  the  unique  t  such  that  c  ::  t  <—>  tc 
in 

Afn  {re  |  r  e  allref s  t  and  subtypep  kl  r  t  and  c  :  r  c— >  re} 

end 


All  loops  in  this  case  of  infer  loop  over  finite  sets,  and  our  induction  hypothesis  tells  us 
that  the  recursive  call  to  infer  terminates. 


Case:  e  =  case  e0  of  C|  =>  et  I  ...  I  Cn  *>  e„  end :t 


The  code  for  this  case  is 


Cn  =>  en  end :t))  = 


infer  VR  (e  as  (case  e<>  ot  c\  ->  e\  I  ... 
if  not  rtom(VR)  I-  e  ::  t  then  ns 
else  let  val  r?  *  infer  VR  eo 
in  if  r?  =  ns  then  ns 

else  let  val  re  -  r  cons  imp  (r?) 
in 

sjoinf  t  {ifn  (infer  VR  eh)  p  u 
h  £  l..n 

J  def 

and  Cfc  ::  u  £— ►  uc 
and  p  €  allref  s  u 

.  def  , 

and  ck  :  p<—>  re} 


end 


end 


By  induction  hypothesis,  all  recursive  calls  to  infer  terminate.  All  other  operations  in  this 
case  are  calls  to  functions  that  terminate  or  iterations  over  finite  sets,  so  this  case  of  infer 
terminates. 


Case:  e  =  (ei,  ...,  e„) 


The  code  for  this  case  is 


I  infer  VR  (ej,  ...,  en)  = 

if  for  any*  in  l..nwehave  infer  VR  e*  =  ns 
then  ns 

else  infer  VR  e\  *  ...  *  infer  VR  e„ 


By  induction  hypothesis,  all  recursive  calls  to  infer  terminate,  so  this  case  of  infer 
terminates. 


Case:  e  =  elt_m_n  e' 


The  code  for  this  case  is 
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I  infer  VR  (elt_m_n  e')  ■ 

let  val  k?  -  infer  VR  e' 

.  in 

if  k ?  =  ns  then  ns 

else  let  val  ky  *  ...  *  kn  =  tuplesimp  ( k ?) 
in  fcm  end 

end 


By  induction  hypothesis,  the  recursive  call  to  inf  er  terminates.  Calls  to  tuples  imp  always 
terminate.  Thus  this  case  of  infer  terminates. 


Case:  e  =  fix  f:t  =>  fn  x:ty  =>  e' 


The  code  for  this  case  is 


I  infer  VR  (e  as  (fix  f:t  =>  fn  x:ty  =>  e'))  = 
let  fun  loop  r  = 

let  val  next?  -  infer  (VR[/ :=  r])  (fn  x:ty  ->  e') 
in 

if  subtypep  next ?  r  t  then  r 
else  if  next ?  -  ns  then  ns 
else  loop  next ? 
end 

val  t\  — *  t2  -  t 
in 

if  t\  ty  then  ns 

else  if  ML  type  inference  does  not  give  rtom(VR)  h  e  ::  ty  -» t2 
then  ns 

else  loop  (botfn  (*i— >£2)) 

end 

We  will  abbreviate  fn  x:ty  =>  e'  as  e". 

If  we  never  get  to  the  call  to  loop  in  this  case  of  infer,  then  we  obviously  terminate 
and  return  ns.  Otherwise,  Theorem  2.100  (Infer  Returns  Some  Type)  on  page  145  and 
Lemma  2.99  (Fix  Case  of  Infer  is  Well-Behaved)  on  page  144  tell  us  that  the  argument  r 
to  loop  always  refines  ty  —*  f2.  By  Fact  2.35  (Splits  of  Arrows  are  Simple)  on  page  51,  r 
has  no  useful  splits,  so  our  induction  hypothesis  applies  and  tells  us  all  recursive  calls  of 
the  form  infer  (VR(/  :=  r])  e"  terminate.  Thus  the  computation  progresses  from  each 
recursive  call  to  loop  to  the  next.  Now  we  have  to  show  that  there  are  only  finitely  many 
recursive  calls,  and  then  we  will  know  that  the  outer  call  to  loop  terminates. 

Let  T-i, r2,. . .  be  the  values  of  r  in  the  successive  recursive  calls  to  loop.  Thus  ry  = 
botfn  (ty  —>  t2).  We  will  show  by  induction  that  for  all  h  >  0  we  have  <  rh+y. 

The  base  case  is  trivial.  Since  ry  =  botfn  (<1  -*  f2),  we  know  that  ry  is  a  subtype 
of  any  refinement  of  ty  -4 12.  Earlier  argument  tells  us  that  r2  c:  ty  — *  t2,  so  this  implies 

7*1  <  7*2. 
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For  the  induction  case,  we  can  assume  that  r^-i  <  rh.  By  definition  of  loop,  rh+\  = 
infer  (VR[/  :=  »•*])  e".  Theorem  2. 100  (Infer  Returns  Some  Type)  on  page  145  therefore 
gives 

VR[/:=r*]he":rfc+l. 

Then  we  can  use  Lemma  2.66  (Environment  Modification)  on  page  81  and  r*_i  <  rh  to  get 


VR[/:=rh_,]l-e'r:rh+l. 


Since  r^-i  C  ti  — > t2.  Fact  2.35  (Splits  of  Arrows  are  Simple)  on  page  51  tells  us  that  rh-\ 
has  no  useful  splits.  Thus  Theorem  2.101  (Infer  Returns  Principal  Type)  on  page  151  gives 

(infer  (VR[/  :=  rH_,])  e")  -<  rh+1. 

By  definition  of  loop,  this  is  equivalent  to 

Th  S  Th+\ , 

which  is  what  we  wanted  to  show.  This  completes  uie  inner  induction. 

Repeated  use  of  trans-sub  with  the  inner  induction  gives 

h  <  j  implies  th  <  rj. 

By  definition  of  loop  and  soundness  of  subtypep,  we  would  not  get  to  iteration  h  +  1  if 
rh+i  <  rh;  thus,  for  all  h  we  have 

rr i+i  %  rh. 

From  this  we  can  use  the  following  reasoning  to  show  that  no  two  of  the  rh’s  are 
equivalent.  Suppose  by  way  of  contradiction  that  =  r,  where  h  <  j.  Then  h  +  1  <  j, 
so  we  have  r^+i  <  Tj.  Then  we  can  use  TRANS-SUB  on  this  and  rh  =  r,  to  get  rh+{  <  rh. 
This  contradicts  our  result  from  the  previous  paragraph,  so  we  cannot  have  rh  =  rj  when 
h  <  j. 

By  Theorem  2.90  (Finite  Refinements)  on  page  1 1 5,  the  sequence  n ,  r2 , . . .  only  contains 
representatix  from  finitely  many  equivalence  classes  of  refinements  of  t\  — ►  t2.  Since  they 
are  all  from  distinct  equivalence  classes,  there  must  be  only  finitely  many  of  them.  Thus 
there  are  only  finitely  many  r^’s,  and  loop  and  this  case  of  infer  always  terminate.  □ 


Chapter  3 

Declaring  Refinements  of  Recursive 
Data  Types 

3.1  Introduction 


The  previous  chapter  defined  refinement  type  inference  in  terms  of  sets  of  refinement 
type  constructors  refining  each  ML  type  constructor.  This  chapter  describes  rectype 
declarations,  which  are  a  compact  way  to  specify  these  sets  of  refinement  type  constructors 
and  the  operations  on  them. 

We  shall  call  the  types  appearing  in  rectype  declarations  recursive  types.  These  types' 
bear  some  resemblance  to  the  recursive  types  of  [AC90];  we  compare  the  two  systems  on 
page  169. 

Because  refinement  type  constructors  must  be  closed  under  intersection,  we  must  either 
require  rectype  declarations  to  include  enough  definitions  to  ensure  closure,  or  we  need 
to  allow  the  theory  to  introduce  refinement  type  constructors  that  do  not  appear  in  any 
rectype  statement.  For  example,  the  declaration 

datatype  bool  =  true  ()  !  false  () 
rectype  tt  -  true  ( runit ) 
and  ff  =  false  (runit) 

does  not  define  a  refinement  type  constructor  for  the  intersection  of  tt  and  ff.  It  would 
better  to  automatically  synthesize  such  a  definition  than  to  require  the  programmer  to 
augment  the  rectype  declaration.  The  theory  below  does  this;  the  synthesized  type  is 
tt  &  ff.  Here  &  is  an  infix  operator  that  combines  one  or  more  of  the  identifiers  defined 
by  the  rectype  statement  (which  we  shall  call  recursive  type  constructors )  to  form  a 
refinement  type  constructor.  Since  &  is  infix,  the  assumption  we  have  made  so  far  that  the 
rectype  statement  above  defines  the  refinement  type  constructors  tt  and  jf  is  true  with  this 
interpretation. 
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Another  concern  is  interacting  smoothly  with  the  global  environment  used  in  the  previ¬ 
ous  chapter.  In  that  chapter,  we  wrote  assertions  like 

nil  d\:  runit  <— >  bliat 

as  though  they  were  simply  true,  instead  of  treating  them  as  assumptions  from  an  explicit 
list  of  assumptions,  or  environment;  to  put  it  another  way,  the  environment  was  an  implicit 
global  variable.  The  environment  never  changed,  so  this  was  very  convenient.  In  contrast, 
the  declarations  introduced  in  this  chapter  specify  new  assumptions  to  add  to  the  environ¬ 
ment.  We  could  clarify  the  manipulation  of  the  environment  by  making  the  environment 
explicit,  but  that  would  create  notational  problems  when  we  refer  to  results  from  the  previ¬ 
ous  chapter,  so  instead  we  will  continue  to  manipulate  it  implicitly.  Since  we  are  describing 
changes  to  the  environment,  we  have  “old”  assertions  that  are  already  in  the  environment 
and  in  this  chapter  we  describe  the  “new”  ones  that  will  be  added.  The  words  “old”  and 
“new”  will  be  used  consistently  in  this  sense  throughout  this  chapter. 

With  this  distinction  in  mind,  we  can  give  the  following  grammar  for  rectype  state¬ 
ments.  The  metavariable  names  in  this  chapter  are  slightly  awkward  because  both  “recur¬ 
sive”  and  “refinement”  start  with  “r”.  We  resolve  the  ambiguity  by  using  “n”  (standing  for 
“new”)  in  the  names  of  metavariables  concerned  with  recursive  types.  For  example,  in  the 
grammar  below,  we  use  the  terminal  nrc  to  stand  for  recursive  type  constructors.  We  also 
use  rc  to  stand  for  old  refinement  type  constructors,  r  to  stand  for  old  refinement  types,  tc 
to  stand  for  ML  type  constructors,  and  c  to  stand  for  new  value  constructors: 

ratmt  ::=  rectype  defn  and  . . .  and  defn 
defn  ;:=  nrc  =  enr 
enr  rc  |  nrc  |  c  (enr)  |  r  — ►  enr  | 

enr  *  ...  *  enr  |  runit  |  bottom  tc  \ 
enr  &  enr  \  enr  I  enr 

In  this  grammar  the  name  of  the  nonterminal  enr  stands  for  extended  recursive  types  (which 
are  slightly  more  flexible  than  the  recursive  types  that  will  be  introduced  below).  Notice 
that  the  metasymbol  “|”  is  used  in  the  grammar  to  define  a  language  construct  containing 
the  character  “  I  ”.  We  shall  assume  throughout  that  the  syntactic  operators  &  and  I  are 
associative,  commutative,  and  idempotent;  thus,  for  example,  tt  &  ff  and  ff  &  it  are  the 
same  syntactic  object. 

The  intuitive  meaning  of  these  declarations  is  fairly  simple:  think  of  them  as  a  notation 
for  defining  sets  of  values.  The  recursive  type  constructor  on  the  left  hand  side  of  the  “=” 
is  defined  by  the  extended  recursive  type  on  the  right  hand  side.  The  extended  recursive 
type  c  (enr)  contains  all  values  that  can  be  constructed  by  applying  the  constructor  c  to 
some  value  in  enr.  The  extended  recursive  type  bottom  ( tc)  contains  no  values  and  it 
refines  tc\  it  should  be  distinguished  from  the  identifier  J.le,  which  is  the  typeset  form  of  the 
identifier  bottom  ^tc  and  can  in  principle  be  given  an  arbitrary  definition  by  the  programmer 
(although  defining  it  as  anything  other  than  bottom  (tc)  would  be  an  unnecessary  surprise). 
The  extended  recursive  type  enri  I  enr2  contains  all  values  appearing  in  either  enri  or 
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enr 2.  The  meanings  of  the  other  extended  recursive  types  should  be  clear  by  analogy  with 
refinement  types. 

The  notation  c  (enr)  is  meant  to  resemble  the  use  of  value  constructors  to  construct 
values.  We  increase  the  resemblance  by  allowing  c  (enri,...  ,enrn)  as  syntactic  sugar 
for  c  (enr  1  *  ...  *  enrn).  To  make  parsing  easier,  we  require  the  parentheses  to  always 
be  present;  this  makes  it  possible  to  parse  rectype  statements  without  knowing  in  ad¬ 
vance  which  identifiers  are  value  constructors  and  which  are  refinement  or  recursive  type 
constructors. 

As  we  did  for  refinement  types,  we  shall  use  runit  to  stand  for  the  empty  tuple  of 
recursive  types.  Comparing  this  grammar  with  the  one  for  refinement  types  on  page  30 
makes  it  clear  that  all  refinement  types  look  like  extended  recursive  types;  although  there 
is  a  natural  correspondence  between  the  two,  it  is  best  to  think  of  them  as  distinct.  Context 
will  make  it  clear  which  is  meant.  An  alternative  would  be  to  add  notation  to  make  the  two 
kinds  of  types  appear  distinct;  this  seems  too  laborious. 

The  notation  bottom  tc  gives  a  way  to  write  types  that  contain  no  values;  we  shall  say 
that  these  types  are  empty.  If  there  are  two  or  more  value  constructors,  we  can  also  write 
an  empty  type  as  an  intersection;  for  example,  given  the  datatype  declaration 

datatype  blist  =  cons  of  bool  *  blist  |  nil  of  tunit 
we  can  write  the  empty  type  as 


rectype  _LWi4<  =  cons  (T iool,  ±klitt)  &  nil  (runit) 

However,  it  seems  better  to  provide  the  bottom  notation  as  well,  since  this  is  more  direct 
approach.  When  we  transform  the  syntax  described  here  into  a  normal  form,  only  the  direct 
approach  will  be  available. 

In  this  thesis,  we  will  require  the  declaration  of  a  datatype  and  the  unique  rectype 
declaration  specifying  refinements  of  that  datatype  to  appear  together.  A  more  general 
approach  would  allow  declaring  a  datatype  followed  by  some  expressions  using  that  datatype 
followed  by  a  declaration  of  refinements  of  that  datatype,  or  even  rectype  declarations 
that  have  their  scope  limited  by  a  let  statement.  In  the  general  case,  two  problems  arise: 
what  to  do  with  the  types  of  variables  in  the  environment  when  entering  the  scope  of  a 
rectype  declaration  and  what  to  do  when  we  leave  the  scope  of  a  rectype  declaration. 
These  problems  seem  solvable,  but  nevertheless  beyond  the  scope  of  this  thesis.  Because 
we  forbid  separating  corresponding  datatype  and  rectype  declarations,  when  we  analyze 
a  rectype  declaration  it  is  possible  to  make  a  clear  distinction  between  “new”  value 
constructors  and  ML  type  constructors  and  “old”  ones:  the  new  constructors  appear  in  the 
associated  datatype  statement,  and  the  old  ones  do  not. 

The  syntax  of  rectype  statements  above  outlaws  recursion  on  the  left  hand  side  of  — > 
by  only  permitting  old  refinement  types  on  the  left  hand  side  of  — This  avoids  situations 
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where  there  is  no  obvious  fixed  point  of  a  declaration;  for  example,  suppose  the  restriction 
were  lifted  and  consider  the  declaration 

datatype  d  =  A  of  d  — *  bool  I  B  of  tunit 

rectype  r  *  A  of  r  — ►  tt 

From  an  intuitive  point  of  view,  it  is  entirely  unclear  how  to  determine  whether  a  particular 
value  is  in  r  because  as  we  include  more  values  in  r,  the  definition  of  r  tells  us  there  are 
fewer  values  in  r.  Formally,  the  problem  with  recursion  on  the  left  hand  side  of  — ►  is  that 
the  definition  of  membership  of  a  value  in  a  recursive  type  in  Figure  3.2  ceases  to  be  a 
monotone  function,  so  we  no  longer  know  that  it  has  a  fixed  point.  This  is  discussed  in 
more  detail  on  page  182  after  we  present  that  definition. 


3.1.1  Outline  of  this  Chapter 

A  rectype  declaration  is  accepted  by  type  inference  if  it  satisfies  some  minor  semantic 
restrictions  described  in  the  next  section  and  it  can  be  rewritten  as  a  set  of  definitions  of  the 
form: 

defn  ::=  nrc  y  c(nr)  |  bottom  (fc) 
nr  ::=  r  — »  nr  |  nr  &  nr  |  re  |  nrc  |  nr  *  ...  *  nr  |  runit 

Unlike  the  previous  grammar,  this  one  only  allows  value  constructors  at  the  top  level,  and 
it  disallows  the  symbol  “1”.  We  have  also  replaced  the  with  this  is  meant  to  imply 
that  we  now  allow  multiple  declarations  of  a  type  for  a  given  nrc  to  (roughly  speaking) 
mean  that  nrc  stands  for  the  union  of  all  the  definitions  that  appear.  The  meaning  is  formally 
defined  in  Section  3.2.  For  example,  rewriting  the  declaration 

datatype  blist  =  cons  of  bool  *  blist  |  nil  of  tunit 
rectype  bev  =  cons  (T**,/  *  cons  (T iooi  *  bev ))  I  nil  (runit) 

starts  by  creating  a  new  type  name  (the  implementation  will  select  names  that  look  like 
g398)  and  results  in  the  set 


{bev  y  cons(T iooi  *  g398), 
bev  y  nil( runit), 
g398  y  cons(T ^  *  bev), 
Tjjjjt  y  cons(T joo /  *  T Uut), 
T uut  y  nil( runit)} 


In  Section  3.3,  we  describe  how  to  infer  that  some  recursive  types  are  empty.  For 
example,  we  can  infer  that  in  the  presence  of  the  declaration  above,  the  recursive  type 
bev  &  g898  contains  no.  values.  This  inference  system  is  only  valid  because  our  con¬ 
structors  are  eager,  if  they  were  lazy,  the  type  bev  &  gS98  would  contain  the  infinite  value 
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cons  (true  (),  cons  (true  (),  ...)),  which  could  be  constructed  by  using  a  fixed  point 
operator. 

In  Section  3.4,  we  describe  how  to  infer  when  one  recursive  type  is  a  subtype  of  another. 
This  inference  system  can  reason  about  empty  types;  for  example,  if  we  add  the  definition 

bem  t  nil(rumt) 


we  can  infer  bev  &  g398  <  bem. 

In  Section  3.5,  we  describe  how  to  infer  that  one  type  is  contained  in  a  union  of  other 
smaller  types.  For  example,  we  can  infer  T nut  ~  {bev,  g 398}. 

In  Section  3.6,  we  define  the  new  refinement  type  constructors  in  terms  of  the  recursive 
type  constructors  appearing  in  the  declaration,  and  we  prove  that  all  of  the  assumptions 
made  in  Chapter  2  about  the  behavior  of  refinement  type  constructors  hold  when  they  are 
defined  by  rectype  statements.  We  also  prove  that  whenever  a  value  has  a  refinement 
type,  it  has  the  corresponding  recursive  type. 


3.1.2  Related  Work 

We  can  think  of  a  recursive  type  as  a  recognizer  for  a  sublanguage  of  the  language  of 
values;  in  this  sense,  a  recursive  type  is  similar  to  a  regular  tree  automaton  as  described  in 
[GS84],  One  difference  is  that  our  language  of  values  includes  functions;  another  difference 
is  that  our  procedure  for  deciding  subtypes  for  recursive  types  is  weaker  than  the  decision* 
procedures  for  deciding  inclusion  of  regular  tree  automata  in  [GS84J,  even  for  recursive 
types  that  contain  no  function  types.  See  the  example  on  page  193. 

The  algorithms  presented  in  this  Chapter  are  similar  to  the  ones  in  [TZ9 1  ] .  Our  recursive 
types  differ  from  their  term  grammars  in  that  we  have  function  types  but  they  do  not,  and 
their  term  grammars  are  closed  under  union  and  complement  but  our  recursive  types  are  not. 
Some  of  the  proofs  below  use  an  induction  principle  that  appears  in  their  paper,  specifically 
induction  on  the  pair  (complement  of  the  trail,  some  tree)  ordered  lexicographically. 

The  algorithms  presented  in  this  Chapter  also  resemble  the  ones  in  [AC90].  The  abstract 
declarations  appearing  here  are  very  similar  to  the  regular  systems  described  in  that  paper, 
and  our  algorithm  for  subtyping  recursive  types  is  a  version  of  the  algorithm  described  on 
page  24  of  that  paper,  modified  to  deal  with  the  features  we  have  added  to  our  type  system. 
Our  recursive  types  disallow  the  recursion  on  the  left  hand  side  of  arrows  that  is  allowed 
in  [AC90],  and  our  system  has  intersections,  which  do  not  appear  in  [AC90].  The  proof 
in  this  chapter  that  the  algorithm  used  here  is  correct  does  not  resemble  theirs  at  all;  they 
reason  about  finite  approximations  to  infinite  trees  to  show  that  their  algorithm  is  consistent 
with  another  axiomatization  of  subtyping,  whereas  we  have  axioms  for  determining  when 
a  value  has  a  recursive  type,  and  we  prove  that  the  inclusion  relation  from  this  algorithm  is 
consistent  with  membership  of  values  in  types. 
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In  both  [AC90)  and  this  chapter,  there  are  two  conceptually  distinct  fixed  points  in 
the  definition  of  membership  of  a  value  in  a  recursive  type.  One  fixed  point  converts  the 
recursive  type  to  a  potentially  infinite  non-recursive  type;  in  [AC90],  this  is  a  least  fixed 
point.  In  this  Chapter,  we  require  each  recursive  definition  to  have  the  form  nrc  y  c(. . .); 
since  the  constructor  c  is  always  present,  the  recursion  makes  progress  and  the  infinite  tree 
is  uniquely  determined.  (In  [AC90],  the  recursive  type  is  rewritten  to  make  the  fixed  point 
unique  before  the  subtyping  algorithm  is  used.) 

The  second  fixed  point  determines  whether  a  value  is  in  this  potentially  infinite  non¬ 
recursive  type.  In  this  chapter,  the  fixed  point  is  a  greatest  fixed  point.  In  f  AC90),  enough 
explicit  types  appear  in  the  terms  to  uniquely  determine  the  fixed  point.  Using  a  greatest 
fixed  point  is  appropriate,  since  we  want  to  assign  as  many  types  to  as  many  terms  as 
possible  while  preserving  soundness. 

There  are  four  important  relations  axiomatized  in  this  Chapter:  membership  of  a  value 
in  a  recursive  type,  emptyness  of  a  recursive  type,  subtyping  for  recursive  types,  and 
splitting  for  recursive  types.  All  of  these  are  greatest  fixed  points  of  the  axiom  system, 
rather  than  the  customary  least  fixed  points.  Informally,  this  means  infinite  proof  trees 
are  permitted.  Formally,  we  think  of  each  inference  system  as  a  monotone  function  and 
consider  a  judgement  to  be  valid  if  it  is  a  member  of  the  greatest  fixed  point  of  the  function. 
A  proof  technique  commonly  used  in  the  literature  (and  in  this  thesis)  with  greatest  fixed 
points  is  co-induction,  as  described  in  [MT91a|,  among  other  places. 


3.2  Abstract  Declarations 


In  the  previous  chapter,  we  assumed  that  information  about  the  primitives  :  ,  <,  and  so 
forth  appeared  in  a  global  environment.  When  type  inference  encounters  datatype  and 
rectype  statements,  the  global  environment  must  be  updated  appropriately.  In  this  chapter, 
we  will  assume  that  the  datatype  statement  has  already  been  added  to  the  environment, 
and  we  will  describe  how  to  add  the  rectype  statement. 

The  proofs  and  inference  systems  are  simpler  if  we  simply  assume  that  &  for  recursive 
types  is  commutative,  associative,  and  idempotent. 

Declarations  given  by  the  programmer  need  to  be  manipulated  in  several  ways  before 
they  become  regular  enough  for  simple  algorithms  to  apply  to  them.  In  this  section  we 
will  informally  describe  how  the  user’s  declarations  are  converted  to  a  normal  form  called 
abstract  declarations,  and  we  will  define  well-formedness  for  abstract  declarations.  All  of 
the  algorithms  described  in  future  sections  take  well-formed  abstract  declarations  as  input. 
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3.2.1  Expansion 

Circular  definitions  of  recursive  type  constructors  are  potentially  confusing.  For  example, 
consider  the  declaration 


datatype  d  -  D  of  d 
and  e  =  E  of  e 
rectype  loop  =  loop 

We  could  decide  that  the  fixed  point  by  which  we  give  meaning  to  these  declarations  is 
a  least  fixed  point,  as  was  done  in  [AC90];  with  this  interpretation  this  declaration  would 
mean  that  loop  is  an  empty  type.  Alternatively,  we  could  decide  that  it  is  a  greatest  fixed 
point,  in  which  case  loop  should  contain  all  of  the  refinements  of  some  ML  type.  However, 
there  is  no  natural  way  to  determine  which  ML  type  loop  refines,  so  instead  this  declaration 
is  considered  an  error.  In  this  Subsection  we  will  detect  all  errors  of  this  kind  by  making 
sure  each  definition  of  a  recursive  type  constructor  makes  progress  before  recurring. 

Define  the  toplevel  of  an  extended  recursive  type  to  be  the  outermost  subterms  of  the 
recursive  type  that  do  not  use  the  “&”  or  “  I  ”  operators.  For  example,  the  toplevel  of  the 
extended  recursive  type 

cons  (T 4 aoi  *  bem)  &  (cons  ( it  *  bnem )  i  bem) 

consists  of  the  subterms  cons  (TiM<  *  bem),  cons  (It  *  bnem),  and  bem.  To  perform 
expansion,  repeatedly  replace  all  refinement  type  constructors  at  the  toplevel  with  their 
definitions  until  there  are  no  refinement  type  constructors  at  the  toplevel,  or  some  definition, 
is  expanded  more  than  once.  If  a  definition  is  expanded  more  than  once,  we  have  a  circular 
definition  and  the  rectype  declaration  is  rejected  as  meaningless. 

For  example,  the  declaration 

datatype  not  =  Succ  of  nat  I  Zero  of  tunit 
rectype  loopl  =  loop2 
and  loop2  -  loopl 

is  rejected  because  attempts  to  expand  the  definitions  of  both  loopl  and  loop2  fail  to 
terminate.  On  the  other  hand,  the  declaration 

datatype  nat  =  Succ  of  nat  I  Zero  of  tunit 
rectype  loopl  -  loop2 

and  loop2  =  Succ  (loopl) 

Is  accepted  and  the  result  of  this  manipulation  is 

datatype  nat  -  Succ  of  nat  I  Zero  of  tunit 
rectype  loopl  =  Succ  (loopl) 
and  loop2  =  Succ  (loopl). 
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3.2.2  Flattening 

Declarations  given  by  the  programmer  will  often  require  inventing  new  refinement  type 
names  to  get  the  expected  effect.  For  example,  with  the  declaration 

datatype  bliat  =  cons  of  bool  *  bliat  I  nil  of  tunit 
rectype  bev  =  cons  (T^  +  cons  (T^/*6et>))  I  nil  ( runit ) 

we  would  expect  the  expression  cons  (true  (),  cons  (true  (),  nil  ()))  to  have  the 
refinement  type  bev.  If  the  only  refinement  of  bliat  is  bev,  we  cannot  infer  this  type  for 
this  expression  because  we  have  no  type  for  the  expression  cons  (true  (),  nil  ()). 
To  get  the  expected  type  for  cons  (true  (),  cons  (true  (),  nil  ())),  we  need  to 
automatically  add  another  refinement  of  bliat.  In  practice,  the  new  refinement  would  be 
given  a  nonmnemonic  name  like  gS98 ,  and  the  rectype  declaration  would  be  treated  as 
though  it  were  written 

datatype  bliat  =  cons  of  bool  *  bliat  I  nil  of  tunit 
rectype  bev  =  cons  (T ^i*gS98)  1  nil  (runit) 
and  g398  -  cons  (T^j  *  bev ) 

(The  programmer  can  define  a  usable  name  for  odd  length  lists  by  doing  this  expansion  by 
hand,  using  some  mnemonic  name  such  as  “bod"  in  place  of  “g 398".)  The  manipulation  of 
the  rectype  statement  that  adds  these  new  recursive  type  constructors  is  called  flattening. 

The  problem  is  that  we  have  value  constructors  that  are  not  at  the  toplevel,  and  the 
solution  is  to  introduce  new  recursive  type  constructors  until  all  value  constructors  are  at 
the  top  level.  To  describe  this  formally,  we  will  have  to  speak  in  terms  of  a  context  C, 
which  is  an  extended  recursive  type  with  a  hole.  For  example,  we  can  write 

cons  (T j*,/  *  cons  (T ^  *  bev))  I  nil  (runit) 

as  C[ T 400;],  where  (?[•]  =  cons  (•  *  cons  (T j00/  *  bev))  I  nil  (runit).  With  this  defini¬ 
tion,  we  can  formally  specify  how  to  flatten  a  rectype  declaration:  whenever  we  encounter 
a  definition  of  the  form 


nrc  =  C[nr\ 

where  the  •  in  £?[•]  does  not  appear  at  the  toplevel,  but  all  toplevel  subexpressions  of  nr 
have  the  form  c  ( nk )  or  bottom  ( tc),  we  choose  a  new  recursive  type  constructor  nkc  and 
replace  this  definition  with  the  two  definitions 

nrc  =  C[nkc\ 
nkc  =  nr 
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The  requirement  that  •  does  not  appear  at  the  toplevel  of  C[-]  is  necessary  ensure  that 
the  manipulation  actually  makes  the  rectype  simpler,  without  the  requirement,  the  result 
of  applying  this  manipulation  to  the  above  example  could  be 

datatype  bliat  3  cons  of  bool  *  bliat  I  nil  of  tunit 
rectype  bev  3  g398 

and  g898  3  cons  (T^  +  cons  (T^  +  ieB))  |  nil  ( runit ) 
which  is  hardly  an  improvement. 

The  requirement  that  all  toplevel  subexpressions  of  nr  have  the  form  c  ( nk )  or 
bottom  (tc)  is  necessary  to  ensure  that  all  refinement  type  constructors  created  by  this 
manipulation  refine  an  ML  type  constructor,  instead  of  refining  some  ML  type.  For  exam¬ 
ple,  without  this  restriction  the  result  of  applying  this  manipulation  to  the  above  example 
could  be 


datatype  bliat  3  cons  of  bool  *  bliat  I  nil  of  tunit 
rectype  bev  3  cons  (T ^ /  *  cons  ( g398 ))  I  nil  (runit) 
and  g898  3  T  *  bev 

which  will  not  satisfy  the  semantic  restrictions  that  appear  below  because  the  new  recursive 
type  constructor  g398  refines  bool  *  bliat,  which  is  not  a  new  ML  type  constructor. 

3.2.3  Simplification 

Now  we  can  manipulate  the  rectype  statement  to  ensure  that  the  toplevel  of  each  definition 
is  simply  a  call  to  a  value  constructor  or  bottom,  rather  than  an  intersection  or  union  of 
calls  to  value  constructors  or  bottom.  We  can  also  eliminate  some  unions;  any  unions  not 
eliminated  by  this  manipulation  cause  an  error. 

Repeat  the  following  rewrites  until  none  of  them  apply: 

•  If  the  definition  has  the  form 


nrc  =  enri  I  enr2 
replace  it  with  the  two  definitions 


nrc  3  enri 
nrc  =  em*2 . 


•  If  the  definition  has  the  form 


nrc  3  c  (enri ) &  c  (ero^) 8c.... 
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replace  it  with 


nrc  *  c  (enri  &  enrz)  & . . . 

•  If  the  definition  has  the  form 

nrc  -  c\  (enr,)&C2  (enr2)&... 
where  C]  and  ci  are  different,  replace  it  with 

nrc  =  bottom  tc 

where  tc  is  the  ML  type  of  the  result  of  cx. 

These  rewrites  will  rewrite  many  rectype  statements  so  each  definition  has  the 
form  nrc  *  c  (enr)  or  nrc  ■  bottom  (tc).  If  they  do  not,  then  the  rectype  state¬ 
ment  is  considered  meaningless;  for  example,  the  results  of  rewriting  may  have  the  form 
nrc  *  enrj  — »  em*2  or  nrc  =  c  (enri)  &  (em*2  *  enr 3).  These  are  and  should  be  disal¬ 
lowed;  the  former  because  the  user  has  apparently  attempted  to  declare  a  new  refinement 
of  — and  the  latter  because  the  new  recursive  type  constructor  must  refine  both  the  output 
type  of  c  (which  must  be  a  datatype)  and  some  tuple  type. 

3.2.4  Adding  Top 

Suppose  we  declare  the  booleans  as 

datatype  bool  -  true  of  tunit  i  false  of  tunit 
rectype  it  -  true  ( runit ) 
and  ff  -  false  (runit). 

If  this  only  gives  rise  to  the  refinement  type  constructors  tt,  ff,  and  tt  &  ff  refining  bool, 
then  there  would  be  no  type  for  an  expression  when  refinement  type  inference  cannot  infer 
that  it  always  evaluates  to  true  ()  or  it  always  evaluates  to  false  ().  For  example,  most 
calls  to  the  function  samelength  defined  by 

fiux  samelength  (cons  (x,  tlx))  (cons  (y,  tly))  =  samelength  tlx  tly 
I  samelength  nil  nil  =  true 
I  samelength  _  _  =  false 

will  get  a  type  error.  Our  options  at  this  point  are  to  declare  that  most  calls  to  samelength 
cause  a  type  error  unless  the  user  adds  a  definition 

...  and  Tfc*/  =  true  (runit)  I  false  (runtf). 
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or  we  could  implicitly  add  the  definition.  Since  there  will  often  be  expressions  where 
refinement  type  inference  does  not  deduce  precise  information,  we  choose  to  implicitly  add 
definitions  of  catch-all  types  like  T ^  to  every  rectype  declaration. 

When  the  value  constructors  have  arguments,  the  added  definitions  win  mention  the 
maximal  refinement  of  other  refinement  types.  For  example,  the  definition  we  would  add 
to 

datatype  d  =  C  of  bool 
rectype  dtrue  -  C  ( tt ) 

would  be 

...  and  Trf  =  C  (Tj00/). 

When  the  datatype  includes  functions,  the  catch-all  refinement  type  will  have  to  have 
minimal  refinement  types  on  the  left  hand  side  of  each  arrow,  as  well.  For  example,  the 
implicit  definition  of  the  catch-all  type  for  the  declaration 

datatype  d  -  C  of  bool  — >  bool 


is 

rectype  Td  =  C  ((tt  ^i) 


and  not 


rectype  T*  =  C 

because  the  latter  does  not  assign  a  type  to  an  expression  C  x  when  x  has  the  type  tt—*tt. 
As  explained  in  Subsection  2.7.2  on  page  74,  we  cannot  yet  construct  values  with  the  least 
type  tt  -*  tt,  but  we  will  be  able  to  in  Chapter  6. 

The  general  procedure  for  creating  catch-all  types  is  straightforward  and  will  not  be 
given  here.  It  starts  to  break  down  when  we  introduce  polymorphic  type  constructors;  see 
Subsection  5.8.3  on  page  272. 

This  procedure  is  not  meaningful  with  a  datatype  declaration  that  is  recursive  on  the 
left  hand  side  of  — ►  such  as 

datatype  d  =  A  of  d  — *■  bool  I  B  of  tunit 

because  the  generated  rectype  declaration  would  have  recursion  on  the  left  hand  side  of 
the  — which  is  not  consistent  with  the  grammar  given  above  for  rectype  statements. 
The  user  cannot  use  a  rectype  statement  to  specify  refinements  of  d  either,  for  the  same 
reason.  The  best  approach  seems  to  be  to  give  datatypes  like  this  exactly  one  refinement, 
which  would  be  called  Tj  in  this  case,  and  to  give  trivial  definitions  of  the  primitives  used 
in  Chapter  2  that  satisfy  the  assumptions  made. 
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3.2.5  Definition  of  Abstract  Declarations 

This  chapter  deals  with  recursive  types,  which  we  define  in  terms  of  recursive  type  con¬ 
structors  and  refinement  types.  We  shall  use  the  following  metavariables  in  this  chapter: 

nrc,  nkc,  npc  Recursive  type  constructors. 
nrcs,  nkcs,  npcs  Sets  of  recursive  type  constructors, 
nr,  nk,  np ,  nq  Recursive  types. 
nrs,  nks ,  nps  Sets  of  recursive  types. 

This  naming  scheme  is  meant  to  be  mnemonic;  “n”  stands  for  “new”,  “s”  stands  for  “set”, 
“c”  stands  for  “constructor”,  and  “r”,  “k”,  “p”  and  “q”  simply  distinguish  multiple  names 
of  each  type.  We  will  also  occasionally  use  metavariables  defined  in  the  previous  chapter. 

After  we  rewrite  rectype  statement  given  by  the  programmer  as  described  above,  we 
can  summarize  the  rectype  statement  as  a  set  D  of  expressions  of  the  form  nrc  X  c(nr) 
or  the  form  nrc  >;  bottom(fc). 

For  example,  the  declaration 

datatype  blist  -  cons  of  bool  *  blist  |  nil  of  tunit 
rectype  be v  -  cons  (TiooJ,  cons  bev))  |  nil  ( runit ) 

and  bod  *  cons  ( T ,  bev) 
and  -Luut  =  bottom  (blist) 

corresponds  to  the  abstract  declaration 


>:  cons(T  j00j  *  T  ui«t), 
T  nitt  h  nil  (runit), 
bev  y  cons(Tiw,<  *  bod), 
bev  >z  nil  (runit), 
bod  >z  cons(T b00i  *  bev), 
-Lbiut  h  bottom  (blist)}. 


The  environments  of  most  of  the  type  inference  rules  below  will  include  an  abstract 
declaration,  usually  called  D.  There  will  be  no  corresponding  description  of  the  ML  type 

clef 

environment;  instead,  we  will  assume  that  appropriate  assumptions  of  the  form  c  ::  t  — >  tc 
reflect  the  datatype  declaration  when  c  is  new.  We  do  thio  because  this  thesis  is  not 
concerned  with  ML  type  inference  and  the  extra  notation  does  not  seem  worthwhile.  A 
complete  description  of  an  ML  dialect  that  included  rectype  declarations  should  have  an 
explicit  environment  that  includes  descriptions  of  the  datatype  declarations  in  effect  as 
well  as  the  rectype  declarations. 
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AND-RECREFINES: 


iJhnrtlt  D  b  nk  C.  t 
D  h  nr  &  nk  C  t 


ARROW-RECREFINES : 


r  C  t\  D  h  nr  C  ti 
D  l-  r  — ►  nr  C  t\  — *  ti 


for  all  c  and  nr  such  that  nrc  X  c(nr)  G  D 

there  is  a  t  such  that  c  1?  t  <-*  tc 
NEW-RECREFlNlJbr  all  tc'  such  that  nrc  >z  bottom  (tc')  G  D 
we  have  tc  =  tc' 

D  h  nrc  C  tc 


OLD-RECREFINES: 


def 

rc  C  tc 


TUPLE- RECREFINES: 


for  all  i  we  have  D  h  nri  i_  U 
D  h  nrj  *  ...  *  nrn  (Z  t\  *  . . .  *  tn 


Figure  3.1:  Monomorphic  Recursive  Type  Refinement  Rules 

3.2.6  Well-formedness 

In  this  section,  we  will  give  some  conditions  that  abstract  declarations  used  in  this  chapter 
must  satisfy.  Rectype  declarations  giving  rise  to  abstract  declarations  that  do  not  satisfy 
these  conditions  are  rejected  by  type  inference. 

Given  an  abstract  declaration,  we  must  first  check  that  it  is  well-formed.  Since  this 
thesis  is  about  refinement  type  inference  and  not  ML  type  inference,  we  will  assume 

without  further  ado  that  assertions  of  the  form  c  d\:  t  «->  tc  derived  from  the  datatype 
statement  are  available.  For  instance,  given  the  declaration 

datatype  blist  -  cons  of  bool  *  blist  |  nil  of  tunit 

we  should  immediately  have  the  assertions 

cons  I'/  (  bool  *  blist )  «— »  blist 
nil  *•?  tunit  (— »  blist. 

Given  these  assertions,  it  is  possible  to  use  the  inference  rules  in  Figure  3.1  to  infer  that 
certain  recursive  types  refine  certain  ML  types. 

These  rules  are  analogous  to  the  monomorphic  refinement  rules  in  Figure  2.3  on  page  3 1 , 
except  we  have  added  a  rule  NEW-RECREFINES  which  is  not  similar  to  any  rule  from 
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Figure  2.3.  This  rule  makes  clear  the  purpose  of  the  “bottom”  declarations  that  can  appear 
in  D ;  they  constrain  the  ML  type  of  recursive  type  constructors  that  would  otherwise 
be  entirely  absent  from  D.  This  is  the  only  place  we  will  use  the  “bottom”  declarations. 
Without  these  declarations,  a  completely  empty  recursive  type  constructor  would  not  appear 
at  all  in  the  abstract  declaration,  so  it  could  refine  all  ML  type  constructors,  which  would 
make  Fact  3.9  (Recursive  Unique  ML  Types)  on  page  179  false. 

As  in  Chapter  2,  we  will  consider  runit  and  tunit  to  be  tuples  of  zero  elements,  so  we 
can  use  the  TUPLE-RECREFINES  rule  to  infer  D  K  runit  C  tunit. 

Now  that  we  can  determine  when  a  recursive  type  refines  an  ML  type,  we  can  say  what  it 
means  for  an  abstract  declaration  to  be  well-formed.  An  abstract  declaration  is  well-formed 
if  the  next  six  conditions  all  hold.  These  conditions  can  all  be  easily  checked  by  a  program. 

First  we  require  all  definitions  in  the  abstract  declaration  to  be  consistent  with  the  ML 
types  of  the  value  constructors: 

Condition  3.1  (Refinement  Consistency)  If  D  is  well-formed  then  for  all  nrc  >  c(nr )  6 
D,  there  are  must  be  t  and  tc  such  that  c  1?  t  <—>  tc  and  D  h  nrc  C  tc  and  D  b  nr  d  t  . 

The  distinction  between  “new”  and  “old”  constructors  mentioned  earlier  is  only  useful 
if  the  new  constructors  are  limited  in  how  they  interact  with  the  old  ones.  An  appropriate 
restriction  is: 

Condition  3.2  (New  Recursive  Type  Constructors  Defined)  Every  well-formed  abstract 
declaration  must  define  all  new  recursive  type  constructors. 

We  need  this  because  there  is  no  way  to  determine  the  ML  type  refined  by  a  new  recursive 
type  constructor  that  does  not  appear  in  the  declaration.  This  restriction  is  satisfied  naturally 
if  the  set  of  new  recursive  type  constructors  is  taken  as  the  recursive  type  constructors  that 
appear  in  the  abstract  declaration. 

Condition  33  (New  Value  Constructors  Defined)  Every  well-formed  abstract  declara¬ 
tion  must  mention  all  new  value  constructors. 

Without  this  restriction,  the  behavior  of  the  new  value  constructors  on  refinement  types 
would  not  be  determined.  This  restriction  is  enforced  naturally  when  catch-all  recursive 
types  are  added. 

Condition  3.4  (New  Value  Constructors  Only)  Every  well-formed  abstract  declaration 
must  not  mention  any  old  value  constructors. 

Without  this,  the  abstract  declaration  could  define  new  refinements  of  old  ML  types.  For 
example: 
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datatype  bool  3  true  of  tunit  I  false  of  (unit 
. . .  some  code  . . . 

datatype  bliat  3  cons  of  bool  *  blist  I  nil  of  {unit 
rectype  tt  -  true  ( runit ) 

We  have  several  more  conditions  that  simply  formalize  some  of  the  behavior  of 
datatype  declarations.  This  restriction  prevents  incrementally  declaring  refinements  of 
existing  data  types: 


Condition  3.5  (New  Value  Constructors  Closed)  The  output  type  of  each  new  value  con¬ 
structor  must  be  a  new  ML  type  constructor. 


Condition  3.6  (Declarations  are  Finite)  All  well-formed,  abstract  declarations  are  finite. 


The  abstract  declaration,  as  written,  gives  one  or  more  definitions  for  some  of  recursive 
type  constructors.  It  is  also  possible  to  think  of  it  as  giving  one  or  more  definitions  for 
some  intersections  of  recursive  type  constructors;  we  call  the  set  of  all  of  the  intersections 
the  closure  of  D,  and  formally  define  it  as  follows: 


Definition  3.7  (Intersection  Membership)  Define  D  to  be  the  set  with  elements  of  the 
form  nrc\  &  ...  &  nrcn  X  c(nr\  &  ...  &  nr„)  where  for  i  between  1  and  n  we  have 
nra  >z  c(nr{)  6  D. 


Simple  reasoning  tells  us  that  Condition  3.1  (Refinement  Consistency)  on  page  178 
extends  naturally  to  intersections  of  recursive  type  constructors: 

Fact  3.8  (Intersection  Refines)  If  c d”  t  <— » tc  and  &nrcs  >z  c(nr)  e  D  then 

D  b  nr  {It 

and 

D  h  &  nrcs  E  tc. 


An  analogue  of  Lemma  2.10  (Unique  ML  Types)  on  page  31  holds  for  recursive  types: 
Fact  3.9  (Recursive  Unique  ML  Types)  If  D  b  nr  C  t  and  D  b  nr  C  u  then  t  =  u. 


The  proof  of  this  is  a  straightforward  induction  on  nr. 
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nra  has  two  or  more  elements 

AND-RECVALUE:  for  each  nr  in  nrs  we  have  D  F  v  e  nr 

D  h  v  G  &nra 


for  all  v  and  all  v'  we  have 

ABS-RECVALUEi"  v  :  r  and  (fn  x  :t  =>  e)  v  =»  v'  imply  D  F  v'  €  nr 

D  F  (f n  x:t  ->  e)  €  r  — »  nr 


new-rc-recvalue: 


nrc  >;  c(nr)  6  D  D  F  t>  €  nr 
D  F  c  v  £  nrc 


OLD-RC-RECVALUE: 


■  F  r  :  rc 
D  h  «  G  re 


TUPLE-RECVALUE: 


for  all  i  we  have  Z)  I-  Vj  €  nr  ^ 

«„)  €  nri  *  ...  *  nrn 


Figure  3.2:  Whether  a  Value  is  in  a  Recursive  Type;  Greatest  Fixed  Point 

3.2.7  Meaning  of  Recursive  Types 

We  can  think  of  recursive  types  as  standing  for  sets  of  values.  In  this  section  we  will 
specify  when  a  value  is  in  a  recursive  type.  For  technical  reasons  described  below,  the 
inference  system  must  be  given  an  unusual  interpretation  that  permits  infinite  proof  trees. 
The  inference  system  is  also  somewhat  unusual  in  that  some  inferences  can  have  infinitely 
many  premises.  Fortunately,  this  inference  system  does  not  need  to  be  decidable.  First  we 
will  explain  why  we  need  infinitely  tall  inference  trees,  and  how  to  formalize  this.  Then  we 
will  explore  various  alternatives  to  the  rule  with  infinitely  many  premises. 

If  one  attempts  to  write  inference  rules  for  proving  that  a  value  has  a  recursive  type, 
apparent  success  comes  quickly.  If  we  write  “with  the  abstract  declaration  D ,  the  value  v 
has  the  recursive  type  nr”  as  D  h  v  e  nr,  then  we  get  the  inference  rules  in  Figure  3.2. 
(The  need  for  the  requirement  of  two  or  more  elements  in  nka  in  the  and-recvalue  rule 
and  the  meaning  of  the  phrase  “Greatest  Fixed  Point”  in  the  caption  will  be  explained  in  a 
moment.) 

An  ordinary  interpretation  of  these  inference  rules  works  well  for  all  values  without 
functions  embedded  in  them.  Unfortunately,  it  is  possible  to  use  function  objects  to  define 
possibly  infinite  lazy  lists  in  ML,  and  a  straightforward  interpretation  of  the  inference  rules 
in  Figure  3.2  draws  wrong  conclusions  in  this  case.  We  can  declare  possibly  infinite  lazy 
lists  of  booleans  with  the  declaration 


datatype  lazy  =  A  of  tunit  -*(bool  *  lazy ) 
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and  we  can  distinguish  lazy  lists  where  all  elements  are  true  ()  with  this  declaration: 
rectype  alltrue  -  A  ( Trinit  — *  it  *  alltrue ) 


The  corresponding  abstract  declaration  is 

D  =  {alltrue  >z  k{runit  —>  tt  *  alltrue)}. 

If  the  function  object  in  a  value  with  ML  type  lazy  fails  to  terminate,  then  it  vacuously 
satisfies  the  abs-recvalue  rule.  Thus  if  we  let 


vo  =  A  (fn  x  =>  (fix  f  =>  fn  x  =>  (f  x))) 


we  have 


D  H  v0  G  alltrue 

and  if  we  let  Vi+i  =  A  (fn  x  =>  (true  () ,  Vi))  for  t  >  0,  we  also  have 

D  H  Vi  €  alltrue. 

However,  because  the  normal  interpretation  of  inference  systems  disallows  infinite  proofs, 
we  cannot  use  the  normal  interpretation  of  this  system  to  give  a  type  to  the  infinite  lazy  list 


A  (fn  _  =>  ((fix  f  =>  fn  _  =>  (true  (),  A  f))  ())). 


There  are  several  possible  ways  to  deal  with  this.  In  theory,  one  could  imagine  a  type 
system  that  gives  no  type  to  the  infinite  lazy  list.  Distinguishing  the  infinite  lazy  list  from 
lists  that  have  a  finite  number  of  elements  followed  by  an  infinite  loop  when  the  next  one 
is  fetched  is  equivalent  to  the  halting  problem,  so  that  type  system  would  also  have  to  give- 
no  type  to  some  finite  lazy  lists.  This  seems  awkward. 

Instead,  we  use  an  informal  interpretation  of  the  above  inference  system  that  permits 
infinite  proofs.  Normally,  the  relation  defined  by  an  inference  system  is  considered  to  be 
the  least  relation  consistent  with  the  inference  rules.  Instead,  we  will  interpret  it  as  the 
greatest  relation  consistent  with  the  inference  rules.  This  is  the  cause  of  the  restriction  of 
and-recvalue  to  sets  of  two  or  more  elements;  if  we  allow  sets  of  one  element,  then  the 
conclusion  of  the  rule  is  the  same  as  the  premise,  and  the  greatest  fixed  point  would  include 
all  possible  conclusions  because  for  any  value  v  and  any  recursive  type  r  we  would  have 
the  infinite  inference  tree 

- ,  — —  [and-recvalue] 

D  I-  v  g  r  :  . 

— -  AND-RECVALUE 

D  1-  v  €  r 


Formally,  we  interpret  this  inference  system  as  the  greatest  fixed  point  of  a  function. 
Take  D  as  fixed  for  the  time  being.  A  greatest  fixed  point  must  be  within  some  universe; 
let  our  universe  U  be  the  set  of  all  possible  pairs  of  the  form  (v,  nr).  We  can  encode  the 
inference  system  in  Figure  3.2  as  a  function  F  mapping  subsets  of  U  to  subsets  of  U.  If  we 
abbreviate  “nr  has  the  form  e”  as  “nr  «  e”,  the  part  of  the  definition  of  F  corresponding 
to  the  AND-RECVALUE  and  ABS-RECVALUE  rules  is: 
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(v,  nr)  €  F(Q)  if  and  only  if 

(nr  oc  8cnks  where  nka  has  2  or  mere  elements,  and 
for  all  nk  in  nka  we  have  (v,  nk)  €  Q) 
or 

( nr<xr—*nk  and  woe  fn  x:t  =>  a  and 
for  all  v"  and  v'  we  have 
if  •  b  w"  :  r 

and  (fn  x:t  =>  e)  v"  =>  v1 
then  (w;,  nib)  6  Q) 
or 

. . .  omitted  cases  . . . 

where  the  omitted  cases  are  always  false  if  nr  oc  8cnks  where  nks  has  2  or  more  elements, 
or  nr  oc  r  — *  nk.  With  this  definition  of  F,  we  say  D  h  v  £  r  if  (w,r)  is  in  the  greatest 
fixed  point  of  F,  which  we  shall  write  as  gfp(F). 

It  is  easy  to  see  that  F  is  monotone.  As  we  admit  more  premises  of  the  form  D  \-  v  £  r, 
we  can  use  the  inference  rules  in  Figure  3.2  to  infer  more  conclusions  of  that  form.  By 
contrast,  if  we  allow  recursion  on  the  left  hand  side  of  arrows,  the  natural  version  of 
ABS-RECVALUE  would  be 

for  all  v  and  all  v'  we  have 

D  v  €  nk  and  (f  n  x :  t  =>  e)  v  =>  v'  imply  D  h  v'  £  nr 
D  h  (fn  x:t  =>  e)  €  nJfe  — *  nr 

which  is  not  monotone,  since  we  have  the  premise  D  h  v  £  nk  on  the  left  hand  side  of  an 
implication. 

Another  option  that  seems  attractive  at  first  is  defining  membership  of  a  function  in  a 
recursive  type  in  terms  of  some  other  type  inference  system.  More  specifically,  we  would 
say  that  fn  x :  t  =>  e  has  the  type  r-*nr  if,  in  some  sense,  when  we  assume  that  *  has 
the  type  r  we  can  infer  that  e  has  the  type  nr.  Unfortunately,  we  do  not  have  a  type 
inference  system  on  hand  that  infers  when  an  expression  with  free  variables  has  a  recursive 
type.  We  could  make  a  recursive  type  inference  system  analogous  to  the  refinement  type 
inference  system  in  Chapter  2,  but  the  description  of  such  a  system  might  be  about  as  large 
as  Chapter  2.  This  inference  system,  on  the  other  hand,  is  concise  and  sufficient  for  our 
purposes. 

We  use  co-induction  to  reason  about  these  greatest  fixed  points,  as  described  in  [MT91b, 
page  216]: 

Fact  3.10  (Co-induction)  Let  U  be  any  set,  and  let  F  be  a  monotonic  function  mapping 
subsets  ofU  to  subsets  of  U.  For  any  Q  C  U,  in  order  to  prove  Q  C  gfp(F),  it  is  suff.  nent 
to  prove  Q  C  F(Q). 

The  first  co-induction  in  this  chapter  is  Theorem  3.20  (Emptyness  Consistency  II)  on 
page  190. 
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Before  we  turn  away  from  membership  of  values  in  recursive  types,  we  note  that  co¬ 
induction  is  not  necessary  in  the  simple  proof  of  an  extended  version  of  new-rc-RECValue 
that  applies  to  intersections  of  recursive  type  constructors: 

Fact  3.11  (Intersection  Value  Membership)  If&nrcs  h  c(nr)  G  D  and  D  h  v  €  nr  then 
D  b  c  v  6  &nrcs. 


3.3  Empty  Types 

The  value  constructors  in  Standard  ML  are  eager,  but  the  simplest  type  systems  are  more 
appropriate  for  lazy  value  constructors.  The  algorithm  introduced  in  this  section  allows 
rectype  statements  to  ignore  certain  distinctions  that  are  unimportant  in  SML,  but  would 
be  important  if  we  had  lazy  value  constructors.  For  example,  if  we  have  the  declarations 

datatype  blist  -  cons  of  bool  *  blist  |  nil  of  runit 
rectype  bev  =  cons  (T *  bod)  I  nil  (runit) 
and  bod  -  cons  (T *  bev) 
and  bnem  =  cons  (T^/  *  Tw;jt) 
and  bem  =  nil  (runit) 

and  value  constructors  are  lazy,  then  bev  &  bod  contains  the  infinite  value 

cons  (true  (),  cons  (true  (),  ...)), 

but  if  value  constructors  are  eager,  there  are  no  infinite  values  and  this  type  is  empty.  By 
contrast,  the  type  bem  &  bnem  is  empty  regardless.  Thus,  if  our  type  system  takes  no 
account  of  the  fact  that  value  constructors  in  SML  are  eager,  we  will  have 

bem  &  bnem  <  bod  &  bev 

but  not 

bod  &  bev  <  bem  &  bnem. 

This  distinction  is  an  unintuitive  nuisance  to  a  programmer  who  expects  value  constructors 
to  be  eager. 

These  unnecessary  distinctions  seem  to  arise  most  often  for  empty  recursive  types.  In 
this  section  we  define  an  algorithm  that  determines  when  a  recursive  type  is  empty  if  value 
constructors  are  call  by  value.  The  definition  of  subtyping  for  recursive  types  that  appears 
in  the  next  section  ensures  that  empty  recursive  types  are  always  subtypes  of  other  recursive 
types  that  refine  the  same  ML  type.  Thus,  we  will  be  able  to  derive 


bod  &  bev  <  bem  &  bnem. 
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def  def  def 

RCON-EMPTY:  rci  A  ...  A  rcn  empty 

b  rei  & . . .  &  rc„  empty 


REF-TUPLE-EMPTY: 


for  some  i  in  1 ...  n  we  have  b  A . . .  A  rm,  empty 
b  (rn  *  . . .  *  rjn)  A  ...  A  (rml  *  ...  *  rmn)  empty 


Figure  3.3:  When  a  Refinement  Type  is  Empty 

We  will  describe  the  algorithm  for  determining  whether  a  recursive  type  is  empty  in 
several  steps.  First  in  Subsection  3.3.1  we  shall  postulate  a  property  of  refinement  type 
constructors  that  says  whether  they  are  empty.  This  can  easily  be  extended  to  a  judgement 
b  r  empty  that  says  when  a  refinement  type  r  is  empty.  We  assume  that  these  judgements 
are  consistent  in  certain  ways.  Then  in  Subsection  3.3.2  we  shall  give  declarative  inference 
rules  for  the  judgement  that  a  recursive  type  is  empty,  written  D  b  nr  empty,  where  D 
is  an  abstract  declaration  and  nr  is  the  recursive  type  in  question.  Infinite  proofs  with 
these  inference  rules  will  be  allowed,  as  they  were  for  the  D  b  t;  €  r  judgement.  We  also 
present  type  inference  rules  for  a  relation  D;  5  b  nr  alg-empty  which  includes  a  set  S  of 
intersections  of  recursive  type  constructors  that  are  presumed  empty.  Proper  use  of  these 
inference  rules  only  allows  finite  proofs,  and  can  be  easily  read  as  an  algorithm.  Then  in 
Subsection  3.3.3  we  will  prove  several  properties  of  these  judgements;  the  most  interesting 
ones  are  that  the  algorithmic  and  declarative  are  equivalent  and  that  types  judged  empty 
actually  contain  no  values. 


3.3.1  Emptyness  for  Refinement  Types 

We  start  by  assuming  that  some  refinement  type  constructors  are  empty.  We  write  the 

def 

assertion  that  re  is  empty  as  re  empty.  If  we  assume  that  certain  refinement  type  constructors 
are  empty,  it  is  straightforward  to  conclude  that  certain  refinement  types  are  empty.  We  call 
the  judgement  for  this  b  r  empty  and  define  it  by  the  rules  in  Figure  3.3. 

def 

For  these  rules  to  work  properly,  we  need  some  consistency  between  the  re  empty 
and  the  b  r  empty  judgements;  we  can  also  regard  these  as  consistency  conditions  on  the 
implicit  global  environment,  as  were  the  assumptions  listed  in  Chapter  2.  First,  if  a  value 
constructor  returns  something  with  an  empty  type,  it  was  given  something  with  an  empty 
type: 


Assumption  3.12  (Emptyness  Constructor)  Ifrc  empty  and  c  :  r  <->  rc  then  b  r  empty. 

Also,  if  a  refinement  type  constructor  is  empty,  any  smaller  refinement  type  constructor 
must  also  be  empty: 


3.3.  EMPTY  TYPES 


185 


Assumption  3.13  (Emptyness  Subtyping)  If  rc  empty  and  kc  <  rc  then  kc  empty. 

These  a  iumptions  are  sufficient  to  show  that  emptyness  for  refinement  types  is  sound, 
in  the  sense  that  empty  refinement  types  contain  no  values: 

Fact  3.14  (Soundness  of  Refinment  Type  Empty)  //hr  empty  and  ■  h  v  ::  t  and  r  [it 
then  we  do  not  have  •  h  v  :r. 

The  proof  of  this  is  a  straightforward  induction  on  v  that  we  shall  omit. 


3.3.2  Emptyness  for  Recursive  Types 

Emptyness  for  recursive  types  is  more  interesting  because  we  must  either  allow  infinite 
proofs  to  get  correct  behavior  in  the  presence  of  recursion,  or  use  trails  to  ensure  termination. 

For  example,  using  the  rectype  declarations  on  page  183,  we  should  be. able  to  infer 
that  bev  &  bod  is  empty.  Suppose,  by  way  of  contradiction,  that  a  value  has  this  type;  then 
the  value  will  be  in  both  bev  and  bod.  By  the  declarations  of  these  types,  the  outermost 
constructor  of  this  value  must  be  cons,  and  the  argument  to  cons  will  be  in  both  of  the 
types  T» ooi  *  bod  and  *  bev.  This  can  only  be  the  case  if  there  is  some  value  in  the 
type  bod  &  bev.  We  assume  that  &  for  recursive  types  is  commutative,  so  this  is  equivalent 
to  the  problem  we  started  with.  We  can  either  continue  to  produce  an  infinite  argument,  or 
we  can  keep  track  of  the  set  of  subproblems  already  encountered  (this  set  is  called  a  trail). 
so  we  can  observe  that  we  have  encountered  this  problem  before  and  stop.  Since  there  are 
actually  no  values  with  this  type,  either  approach  should  lead  to  the  conclusion  that  the  type 
is  empty. 

If  we  take  the  approach  of  permitting  infinite  proofs,  we  get  the  inference  system  in 
Figure  3.4.  For  this  example,  the  infinite  proof  tree  for  D  h  bev  &  bod  empty  is 


D  1-  bod  &  bev  empty 


[new-enfer-empty] 


D  h  T  4 00i  *  bod  &  T  igol  *  bev  empty 
D  h  bev  &  bod  empty 


[rec-tuple-empty] 

[new-infer-empty] 


Finding  an  intuitively  meaningful  reading  is  straightforward,  with  the  possible  exception 
of  NEW-INFER-EMPTY.  Translating  it  into  words  yields  “If  the  only  way  to  construct  an 
element  of  a  recursive  type  nr  is  by  starting  with  elements  of  other  types  that  are  all  empty, 
then  nr  is  empty.”,  which  seems  plausible. 

If,  instead,  we  take  the  approach  of  using  a  trail  to  keep  track  of  the  pending  subproblems, 
we  get  the  inference  system  in  Figure  3.5.  In  this  system,  the  trail  is  the  set  5,  which 
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for  all  c  and  all  rt  such  that  &nrca  >z  c(nr)  e  D  we  have 

NEW-INFER-EMPTY:  D  \-  nr  empty _ 

D  F  &nrc8  empty 

def  def 

OLD-EMPTY:  A  res  empty _ 

D  F  &rca  empty 

for  some  i  in  1 ...  n  we  have  D  F  nru  & ...  &  nrm<  empty 
rec-tuple-empty:  d  f  (nru  *  _  *  nrin)  &  &  (nrmi  „  _  „  nrmn)  empty 

Figure  3.4:  Declarative  Emptyness  for  Recursive  Types  (Greatest  Fixed  Point) 


ALG-NEW-ENV-EMPTY: 


&  nrca  e  S 

D;  S  F  &ntvs  alg-empty 


for  all  c  and  all  rt  such  that  &nrcs  >z  c(nr )  eD  we  have 

ALG-NEW-INFER-EMPTY:  D\  S  U  {&nrca}  F  nr  alg-empty _ 

D;  5  F  &nrcs  alg-empty 


def  def 

ALG-OLD-EMPTY:  A  res  empty _ 

D;  S  h  &rc8  alg-empty 

for  some  i  in  1 ...  n  we  have 

ALG-REC-TUPLE-EMPTY: _ D;  S  \~  nru  & . . .  &  nrmi  alg-empty _ 

D,S  h  (nrM  *  ...  *  nrJn)  &  ...  &  (nrmi  *  ...  *  nrmn)  alg-empty 


Figure  3.5:  Algorithmic  Emptyness  for  Recursive  Types 

contains  the  intersections  of  recursive  type  constructors  that  we  are  already  attempting  to 
prove  empty.  For  example,  the  following  derivation  is  a  proof  that  bev  &  bod  is  empty: 


D ;  {bev  &  bod}  F  bod  &  bev  alg-empty 
D ;  {bev  &  bod}  F  Tj *  bod  &  Tj^j  *  bev  alg-empty 
D\  {}  F  bev  &  bod  alg-empty 


[alg-new-env-empty] 

[alg-rec-tuple-empty] 
[alg-new-infer-empty] 


This  inference  system  can  easily  be  read  as  an  algorithm.  Simply  try  to  construct  a 
derivation  starting  at  the  root  with  an  empty  trail,  and  use  ALG-NEW-ENV-EMPTY  instead  of 
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alg-NEW-INFER-EMPTY  whenever  a  choice  arises.  Informally  speaking,  the  algorithm  for 
inferring  D;  S  nr  alg-empty  is  sure  to  terminate  because  at  each  step  either  5  stays  the 
same  and  nr  gets  smaller,  or  S  gets  larger.  Since  D  is  finite  and  S  contains  intersections 
of  sets  of  recursive  type  constructors  mentioned  in  D,  the  largest  possible  5  is  finite. 
Formalizing  this  requires  introducing  two  new  definitions:  a  measure  of  the  size  of  nr  that 
we  shall  call  depth( nr)  and  the  maximal  value  of  S  which  we  call  emptyU(Z)). 

Because  of  the  alg-REC-TUPLE-EMPTY  rule,  we  cannot  say  that  if  5  remains  constant, 
nr  is  replaced  by  a  subterm  of  itself.  For  instance,  given  the  problem  D;S  t-  (tt  * 
ff)  &  (ff  *  ff )  alg-empty,  we  would  examine  the  subproblems  D;  S  h  tt  &  ff  alg-empty 
and  D;  S  f-  ff  &  ff  alg-empty.  Neither  of  these  recursive  types  appear  literally  within 
(tt*  ff)&(ff*  ff).  They  are  smaller  in  the  sense  that  their  printed  representation  is  smaller, 
but  this  is  awkward  to  reason  about.  Instead  we  regard  the  recursive  type  as  a  tree,  and  think 
in  terms  of  the  height  of  the  tree.  Since  &  for  recursive  types  is  assumed  to  be  idempotent, 
we  have  to  give  the  same  “height”  to  both  tt  &  tt  and  tt;  thus  we  call  it  “depth”  to  distinguish 
it  from  the  ordinary  notion  of  tree  height,  and  we  define  it  so  intersection  operators  do  not 
increase  the  measure  of  a  recursive  type: 

Definition  3.15  (Depth  of  a  Recursive  Type)  We  define  the  depth  of  a  recursive  type  by 
the  equations 

depth(&nrs)  =  max{depth(nr)  |  nr  6  nrs} 
depth(r  — >  nr)  =  depth(nr)  +  1 
depth(rti  * ...  *  rtn)  =  max{depth(wj  |  i  €  1 . . .  n)}  +  1 
depth(rc)  =  0 
depth(wrc)  =  0. 

By  Condition  3.2  (New  Recursive  Type  Constructors  Defined)  on  page  178,  all  recursive 
type  constructors  that  can  appear  in  5  are  defined  in  D.  Thus  we  can  define  the  universe 
from  which  S  is  chosen  as  all  possible  subsets  of  the  types  defined  in  D: 

Definition  3.16  Define  emptyU(Z?)  to  be  {&.nrcs  \  all  nrc  €  nrcs  are  defined  in  D}. 

With  these  definitions,  we  can  say  that  the  natural  algorithm  derived  from  the  rules  in 
Figure  3.5  terminates  because  the  pair  (emptyU(D)  -  5,  depth(  nr))  always  lexicographi¬ 
cally  decreases.  Not  surprisingly,  this  measure  will  also  ensure  that  some  induction  proofs 
below  make  progress. 


3.3.3  Properties  of  Empty 

We  shall  show  that  the  algorithmic  and  declarative  versions  of  emptyness  inference  are 
equivalent,  and  that  types  judged  empty  actually  contain  no  values. 
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Fact  3.17  (Algorithmic  Emptyness  Strengthening)  If  D\  S\\~  nr  alg-empty  then 

D\  S\  U  52  F  nr  alg-empty. 

Proving  this  is  a  trivial  induction  on  the  derivation  of  the  hypothesis.  The  derivation  of 
D;  Si  U  S2  h  nr  alg-empty  has  the  same  shape  as  the  derivation  of  D;  S\  f-  nr  alg-empty; 
the  only  difference  is  that  in  the  former  derivation  all  of  the  trails  are  larger. 


Lemma  3.18  (Empty  Eliminable  Assumptions)  If 

D;  {}  F  &nkcs  alg-empty 


and 

then 


D\  S  U  {&nkcs}  F  nr  alg-empty 
D;S  nr  alg-empty. 


Proof:  By  induction  on  the  derivation  of  D;  S  U  { &nkcs }  F  nr  alg-empty. 

Case:  ALG-NEW-ENV-EMPTY,  nr  =  &nkcs  Applying  Fact  3.17  (Algorithmic  Emptyness 

Strengthening)  on  page  188  to  D;  {}  F  &nkcs  alg-empty  gives  D,S  F  &nkcs  alg-empty, 
which  is  our  conclusion. 

Case:  ALG-NEW-ENV-EMPTY,  nr  ^  &nkcs  Then  nr  ex  &nrcs  where  the  premise  of  ALG- 

NEW-ENV-EMPTY  is  &nrca  £  S  U  {&n*cs}.  Since  nr  ^  &nkcs,  this  implies  &nrcs  £  S, 
and  ALG-NEW-ENV-EMPTY  gives  D\  S  h  &nrca  alg-empty,  which  is  our  conclusion. 

Case:  ALG-NEW-INFER-EMPTY  Then  nr  cx  &nrcs  and  the  premise  of  ALG-NEW-INFER- 
EMPTY  must  be 

for  all  c  and  all  nk  such  that  &nrcs  c(nk)  £  D  we  have 
D;  S  U  {&nifecs,&nrcs}  F  nk  alg-empty. 

By  induction  hypothesis, 

for  all  c  and  all  nk  such  that  A nrca  X  c(nk)  £  D  we  have 
D;S  U  {&nrcs}  F  nk  alg-empty. 

and  ALG-NEW-INFER-EMPTY  gives  our  conclusion. 

Case:  ALG-OLD-EMPTY  Then  nr  <x  &rcs  and  the  premise  of  ALG-OLD-EMPTY  is 

def 

F  A  res  empty.  ALG-OLD-EMPTY  gives  our  conclusion. 
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Case:  ALG-REC-TUPLE-EMPTY  Then  nr  a  (nru  * ...  *  nr!n)  & ...  &  (nrmi  *  ...  *  nrmn) 
and  the  premise  of  ALG-REC-TUPLE-EMPTY  is 

for  some  t  in  1 ...  n  we  have  D\  S  U  {&nJbca}  h  nru  &....&  nrm{  alg-empty. 

By  induction, 

for  some  i  in  1 ...  n  we  have  D\  S  h  nru  &....&  nrmt  alg-empty, 

and  ALG-REC-TUPLE-EMPTY  gives  our  conclusion.  □ 

Now  we  can  show  that  the  algorithmic  and  declarative  versions  of  emptyness  infer¬ 
ence  are  equivalent.  We  have  separate  proofs  showing  each  is  at  least  as  strong  as  the 
other.  The  first  proof  is  by  induction  on  the  pair  (emptyU(D)  -  5,  depth( nr))  ordered 
lexicographically;  the  second  is  the  first  co-induction  in  this  chapter. 

Theorem  3.19  (Emptyness  Consistency  I)  //  D  h  nr  empty  and  for  all  &nrcs  £  S  we 
have  D  h  &nrcs  empty  then  D;S  b  nr  alg-empty. 

Proof:  By  induction  on  the  pair  (emptyU(D)  -  S,depth(nr)),  ordered  lexicographically. 
The  declarative  emptyness  rules  constrain  the  form  of  nr,  so  we  have  the  following  cases: 

Case:  nr  oc  &nrcs  If  nr  £  S,  then  ALG-NEW-ENV-EMPTY  gives  our  conclusion. 

Otherwise,  the  last  inference  of  J9  H  nr  empty  must  be  new-infer-empty  with  the 
premise 

for  all  c  and  all  nk  such  that  &nrca  X  c(nk)  £  D  we  have  D  h  nk  empty. 

Combining  the  two  hypotheses  of  this  theorem, 

for  all  &nkcs  £  S  U  {&nrc3}  we  have  D  H  &nkcs  empty. 

The  induction  hypothesis  gives 

for  all  c  and  all  nk  such  that  &nrcs  >:  c(nk)  £  D  we  have 
D;  S  U  {&nrca}  h  nk  alg-empty, 

and  ALG-NEW-INFER-EMPTY  gives  our  conclusion. 

Case:  nr  «  &rcs  Then  the  last  inference  of  Z?  H  nr  empty  is  OLD-EMPTY  with  the 

def  def  _ 

premise  A  res  empty  and  alg-OLD-EMPTY  gives  D;S  r  nr  alg-empty,  which  is  our 
conclusion. 
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Case:  nr  oc  (nru  *  ...  *  nrln)  & ...  &  (nrml  *  . . .  *  nrmn)  Then  the  last  inference  of 
D  b  nr  empty  is  REC-TUPLE-EMPTY  with  the  premise 

for  some  *  in  1 ...  n  we  have  D  1-  nru  nrmi  empty. 

The  induction  hypothesis  gives 

for  some  *  in  1 ...  n  we  have  D\  S  b  nru  &  ...  &  nrmi  alg-empty. 
and  ALG-REC-TUPLE-EMPTY  gives  our  conclusion.  □ 

Theorem  3.20  (Emptyness  Consistency  II)  If  D\  {}  b  nr  alg-empty  then  D  I-  nr  empty. 

Proof:  By  co-induction.  Take  D  to  be  fixed,  and  let  F  be  the  natural  encoding  of  the 
rules  in  Figure  3.4  as  a  function  from  sets  of  recursive  types  to  sets  of  recursive  types.  Let 
Q  =  {nr  |  D;  {}  b  nr  alg-empty};  thus  our  goal  is  to  show  Q  C  gfp (F).  By  co-induction, 
it  suffices  to  show  Q  C  F(Q).  Let  nr  be  an  element  of  Q.  We  will  show  by  cases  on  nr 
that  nr  is  in  F(Q)  as  well. 

Case:  nr  oc  &nrcs  The  last  inference  of  D\  {}  b  nr  alg-empty  must  be  alg-new- infer  - 
EMPTY  with  the  premise 

for  all  c  and  all  nk  such  that  &nrcs  X  c(nlfe)  G  D  we  have  D ;  {&nrcs}  b  nk  alg-empty. 
By  Lemma  3.18  (Empty  Eliminable  Assumptions)  on  page  188  we  have 

for  all  c  and  all  nk  such  that  &nrcs  >z  c{nk)  £  D  we  have  D;{}\~  nk  alg-empty 
and  the  definition  of  Q  gives 

for  all  c  and  all  nk  such  that  &nrcs  >z  c(nk)  G  D  we  have  nk  G  Q. 

By  NEW-INFER-EMPTY,  this  implies  &nrcs  G  ^(Q),  which  is  what  we  wanted  to  show. 

The  next  two  cases  are  trivial,  but  they  are  also  short,  so  we  include  them  for  complete¬ 
ness. 

Case:  nr  oc  &ncs  The  last  inference  of  D\  {}  b  nr  alg-empty  must  be  ALG-OLD-EMPTY 

with  the  premise  A*  res  empty.  By  OLD- EMPTY,  this  implies  nr  G  F(Q),  which  is  our 
conclusion. 

Case:  nr  oc  (nru  *  ...  *  nrin)  & ...  &  (nrmi  *  ...  *  nrmn)  Then  the  last  inference  of 
D;  {}  b  nr  alg-empty  is  ALG-REC-TUPLE-EMPTY  with  the  premise 

for  some  i  in  I ...  n  we  have  D\  {}  b  nru  & . . .  &  nrmi  alg-empty. 
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The  definition  of  Q  gives 

for  some  t  in  1 ...  n  we  have  nr^  & ...  &  nrmj  G  Q. 

REC-TUPLE-EMPTY  then  gives  nr  G  F(Q),  which  is  our  conclusion.  □ 

We  shall  say  that  the  last  inferences  of  a  derivation  have  some  property  if  every  path 
from  the  root  of  the  derivation  starts  with  one  or  more  inferences  that  have  that  property. 
For  an  example,  see  the  first  case  of  the  following  proof. 

Theorem  3.21  (Soundness  of  Empty)  We  never  have  D\-  nr  empty  and  D  h  v  g  nr. 


Proof:  By  induction  on  v. 


Case:  v  oc  c  v'  where  c  is  new 


Then  the  last  inferences  of  the  derivation  of  JD  l~  u  €  nr 


must  be  and-recvalue  and  NEW-RC-RECVALUE,  so  nr  oc  &nrcs.  The  last  inference  of 
D  I-  nr  empty  must  be  NEW-INFER-EMPTY  with  the  premises 


for  all  c  and  all  nk  such  that  &nrcs  X  c(nk)  G  D  we  have  D  F  nk  empty.  (3.1) 


The  premises  of  AND-RECVALUE  and  NEW-RC-RECVALUE  leading  up  to  D  I-  v  G  nr  must  be 

for  all  nrc  6  nrcs  there js  a  npnrc  such  that 

nrc  >z  c(npnn)  G  D  and  (3.2) 

D\-v'e  npnre. 

By  definition  of  intersection  membership, 

&nrcs  t  c(&{np nrc  |  nrc  6  nres})  6  D 


thus  (3.1)  gives 


D  h  &{npnre  |  nrc  G  nrcs}  empty. 


Applying  and-recvalue  to  (3.2)  gives 


D  H  v1  G  &{npnrc  |  nrc  G  nrcs}. 


The  induction  hypothesis  applied  to  the  last  two  displayed  formulae  yields  our  contradiction. 


Case:  v  oc  c  v1  where  c  is  old 


Then  the  last  inferences  of  D  \~  v  E  nr  must  be  AND- 


RECVALUE  and  OLD-RC-RECVALUE,  so  nr  oc  &rcs  and  for  all  rc  in  res  we  have  -he  v' :  re. 
By  AND- INTRO-TYPE  we  have 

•  h  c  v' :  &rcs. 


The  last  inference  of  D  b  nr  empty  must  be  OLD-EMPTY  with  the  premise  A  res  empty; 
RCON-EMPTY  then  gives  F  &rcs  empty  and  by  Fact  3.14  (Soundness  of  Refinement  Type 
Empty)  on  page  185  we  do  not  have 


•he  v1 :  &rcs. 
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This  is  our  contradiction. 

Case:  v  oc  («i ,  . . .  f  «„)  Then  the  last  inferences  of  D  1-  v  £  nr  must  be  and-RECVALUE 

and  TUPLE'RECVALUE,  so  nr  oc  (nru  *  ...  *  nri„)  &  ...  &  (nrmi  *  ...  *  nrmn).  Thus  the 
last  inference  of  D  nr  empty  must  be  REC- TUPLE-EMPTY  with  the  premise 

for  some » in  1 ...  n  we  have  D  h  nru  & ...  &  nrmi  empty.  (3.3) 

The  premises  of  and-recvalue  and  tuple-recvalue  leading  up  to  D  I-  v  £  nr  must  be 

for  all  i  in  1 . . .  n  and  all  j  in  1 ...  m  we  have  D  V{  £  nrji 

and  AND-RECVALUE  gives 

for  all  t  in  1 ...  n  we  have  D  h  £  nrii  &  ...  &  nrmi.  (3.4) 

Our  induction  hypothesis  applied  to  (3.3)  and  (3.4)  gives  our  contradiction. 

Case:  v  <x  f n  x:t  =>  e  Then  the  last  inferences  of  D  I-  v  £  nr  must  be  ABS-RECVALUE 

and  AND-RECVALUE,  so  nr  oc  rx  — >  nrx  &  ...  &  rn  — +  nr„  and  there  is  no  way  to  infer 
D  h  nr  empty.  □ 

The  intersection  of  an  empty  recursive  type  and  any  other  recursive  type  is  also  empty, 
if  it  the  intersection  is  well-formed.  We  include  the  proof  to  give  another  example  of 
an  ordinary  co-induction  proof,  slightly  more  complex  than  Theorem  3.20  (Emptyness 
Consistency  II)  on  page  190. 

Theorem  3.22  (Empty  Intersection)  If  D  f-  nr  empty  and  D  1-  nr  &  nk  C  t  then  D  I- 
nr&nk  empty. 

Proof:  By  co-induction.  Take  D  as  fixed,  and  let  F  be  the  natural  description  of  the  rules 
in  Figure  3.4  as  a  function  from  sets  of  recursive  types  to  sets  of  recursive  types.  Let 
Q  =  {nr  &.nk  \  D  nr  empty  and  there  is  a  t  such  that  D  \-  nr  Scnk  c  £}.  We  need  to 
show  Q  C  gfp(jF);  by  co-induction,  it  suffices  to  show  Q  c  F(Q).  Let  nr  &  nk  be  an 
arbitrary  element  of  Q\  it  suffices  to  show  that  nr&nk  £  F(Q).  We  take  cases  on  the  form 
of  nr. 

Case:  nr  oc  &nrcs  Then  by  definition  of  Q  we  have  D  \-  8tnrcs  empty  and  D  H 

(&nrcs)  &  nk  C.  t.  We  can  only  infer  the  latter  if  nk  «  &nkcs.  The  last  inference  of 
D  K  &nrcs  empty  must  be  NEW- INFER- empty  with  the  premise 

for  all  c  and  all  nr'  such  that  &nrcs  >z  c(nr')  £  D  we  have  D  h  nr'  empty. 

Let  c  and  np  be  given  such  that  &(nrcsUnkcs)  >z  c(np)  £  D.  By  definition  of  intersection 
membership,  we  can  write  np  as  nr'&nk'  where  &nrcs  x  c(nr').  By  Fact  3.8  (Intersection 
Refines)  on  page  179,  there  is  a  u  such  that  D  F  nr'  &  nk'  C  u,  so  the  definition  of  Q  gives 

for  all  c  and  all  np  such  that  &(nrcs  U  nkcs)  >z  c(np)  £  £>  we  have  np  £  Q 
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Thus,  by  NEW-INFER-EMPTY,  &(nrcs  U  nkca )  G  F(Q),  which  is  our  conclusion. 


Case:  nr  oc  &rca 


Since  D  h  nr  &  ni  C  t,  we  know  nk  oc  &kcs.  The  last  inference  of 


def  def 

D\~  nr  empty  must  be  OLD-EMPTY  with  the  premise  A  res  empty.  Simple  reasoning  about 

def  .  .def  def  .def  .  def  .def  .  . 

A  gives  (A  rca)  A(A  scs)  <  (A  rca),  so  Assumption  3.13  (Emptyness  Subtyping)  on 

page  185  gives  ( *A  rcs)dAf(dA  kca)  empty.  OLD-EMPTY  then  gives  (&rcs)&(&kcs)  g  F(Q), 
which  is  our  conclusion. 


Case:  nr  oc  (nru  *  ...  *  nri„)  & ...  &  (nrmi  *  ...  *  nrron) 


Since  D  h  nr  &  nk  C  t. 


we  must  have  nk  oc  (nk n  *  ...  *  nfci„)  &  ...  &  (nkqt  *  ...  *  nkqn).  The  last  inference 
of  D  \~  nr  empty  must  be  REC -TUPLE-EMPTY  with,  for  some  i,  the  premise  D  (-  nrti  & 
...  &  nrmi  empty.  Simple  reasoning  about  recursive  refinement  types  gives  a  u  such 
that  D  1-  nri,-  &  ...  &  nrmt-  &  nku  &  . . .  nkqi  C  u.  The  definition  of  Q  then  gives 
nru  & ...  &  nrmi  &  nku  &  . . .  nib^  G  Q,  then  REC-TUPLE-EMPTY  gives  nr  &  nk  G  F(Q), 
which  is  our  conclusion.  □ 


3.4  Subtyping 


The  type  inference  system  for  subtyping  recursive  types  is  similar  to  the  system  in  the 
previous  section  for  inferring  when  a  type  is  empty.  For  subtyping  we  have  two  similar 
systems,  one  declarative  using  a  greatest  fixed  point  and  no  trail,  and  one  algorithmic 
using  a  least  fixed  point  and  a  trail.  In  this  case  a  trail  is  a  set  with  elements  of  the  form 
(&nrca,&nAcs);  each  element  represents  the  assertion  that  we  are  already  working  on  the 
problem  D  h  &nrca  <  &nkca. 

The  declarative  system  is  described  in  Figure  3.6,  and  the  algorithmic  system  is  Fig¬ 
ure  3.7.  The  OLD-RECSUB  and  TUPLE-RECSUB  rules  are  self-evident;  explanations  of  the 
other  two  follow. 

One  way  to  understand  the  NEW-INFER-RECSUB  rule  is  by  walking  through  a  sketch  of 
that  case  of  Theorem  3.34  (Recursive  Subtype  Soundness)  on  page  204.  Suppose  some 
value  c  v  is  in  &nrca.  Then  there  must  be  some  definition  of  &nrcs  of  the  form  c(nr) 
where  v  is  in  nr.  If  nr  is  empty,  then  we  have  a  contradiction  and  we  are  done.  Otherwise, 
if  there  is  a  definition  of  &nkca  of  the  form  c(nk )  for  some  nk  larger  than  nr,  then  v  is  in 
nk  and  c  v  is  in  &nkcs. 

Although  this  rule  is  sound,  it  could  be  stronger.  For  example,  consider  the  declaration 


datatype  d  =  C  of  bool 
rectype  d,  =  C  (T4to,) 

and  dt  =  C  ( tt )  I  C  ( ff ) 
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NEW-INFER-RECSUB: 


D  b  &  nrca  C  tc 
D  b  &  nkca  C.  tc 

for  all  c  and  all  nr  such  that  &nrca  >z  c(nr )  G  D 
either  D\-  nr  empty 

or  there  is  a  nib  such  that  &nkca  y  c(nk)  G  D  and  D  h  nr  <  nk 
D  f-  Scnrcs  <  &nkca 


D  b  &  {rj  — >  |  x  G  1 . . .  n}  C  t 

ARROW-RECSUB: for  j  G  1 ...  m  we  have  D  b  &{nrj  j  i  G  1 . .  .n  and  fc,  <  r,}  <  nkj 
D  I-  &{ri  —*  nri  |  »  G  1 . . .  n}  <  &{kj  — »  nkj  \  j  G  1 . . .  m} 


OLD-RECSUB: 


.del  del  del  . 

(A  res)  <  (A  kca) 
D  b  &res  <  &kcs 


for  *  G  1 ...  n  we  have  D  b  nrg  &  ...  &  nrmj  <  nkn  & ...  &  nkqi 
TUPLE-RECSUB:  #  b  (nrn  *  . . .  *  nri*)  &  . . .  &  (nrml  *  . . .  *  nrmn)  <  . 

(nin  *  ...  *  nk\n)  & ...  &  ( nkql  *  ...  *  nk^) 

Figure  3.6:  Declarative  Rules  for  Recursive  Subtyping  (Greatest  Fixed  Point) 

With  this  declaration,  all  values  in  dt  are  also  in  dt,  but  if  we  convert  this  declaration  into 
an  abstract  declaration  D  we  cannot  infer  D  b  dt  <  dt.  The  cause  of  this  is  that  T  iool  is 
less  than  the  union  of  tt  and  ff,  but  it  is  not  less  than  either  tt  or  ff  taken  individually.  Since 
it  is  possible  to  decide  whether  the  language  recognized  by  one  regular  tree  automaton  is  a 
subset  of  the  language  recognized  by  another  ([GS84]),  and  rectype  statements  that  do  not 
contain  »”  are  essentially  descriptions  of  regular  tree  automata,  it  is  in  principle  possible 
to  make  a  practical  system  that  is  complete  in  the  first-order  case. 

The  ARROW-RECSUB  rule  is  motivated  by  Lemma  2.83  (i  Gives  an  Upper  Bound)  on 
page  111.  It  would  probably  be  possible  to  take  the  approach  of  Chapter  2  and  have  simple 
axioms  defining  recursive  type  inference  and  then  restructure  the  system  completely  to  find 
a  practical  algorithm  that  uses  ARROW-RECSUB,  but  such  an  analysis  might  be  as  long  as 
Chapter  2.  Our  grammar  does  not  admit  &  with  zero  arguments,  so  this  rule  does  not  apply  if 
any  of  the  sets  mentioned  are  empty.  For  example,  suppose  D  includes  the  usual  definitions 
of  refinements  of  bool  and  we  are  trying  to  prove  the  false  assertion  D  b  tt^ff 
then  one  of  the  premises  would  have  to  be  D  b  A{}  <  tt,  which  is  malformed. 

The  algorithmic  and  the  declarative  systems  are  consistent  in  the  same  sense  the  systems 
for  emptyness  were  consistent.  The  proof  is  entirely  analogous  to  the  proof  that  the  systems 
for  emptyness  are  consistent.  We  start  by  establishing  that  we  can  manipulate  the  trail: 


Fact  3.23  (Subtype  Strengthening)  If  Sf  c  S  and  D,  S'  b  nr  <nk  then  D\  S  b  nr  <  nk. 
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ALG-NEW-ENV-RECSUB: 


D  &  nrcs  (Z  tc 
D  h  &  nkca  C  tc 
( Scnrca ,  Scnkcs )  G  S 
D;S  h  &nrc8  <  Scnkcs 


D  b  &  nrcs  Cl  tc 
D  h  &  nkca  \Z  tc 

for  all  c  and  all  nr  such  that  &nrcs  y  c(nr)  G  D 
ALG-NEW-INFER-RECSUB:  either  D  h  nr  empty 

or  there  is  a  nib  such  that 

&nkcs  y  c(nk )  6  D  and  D,  S  \~  nr  <  nk 
D\S  I-  Scnrca  <  Scnkcs 


ALG-ARROW-RECSUB: 


D  h  &  {rj  -»  nrj  |  t  6  1 . . .  n}  IZ  t 
for  j  G  1 ...  m  we  have 

_ P;  5  I-  &{nr,  |  i  6  1 . . .  n  and  kj  <  r;}  <  nkj _ 

D,S  h  &{rj  — *•  »r<  1 1  €  1 . . . »}  <  Sc{kj  —*  nkj  \  j  G  1 . . .  m\ 


.def  dcf  def 

ALG-OLD-RECSUB:  (A  res)  <  (A  kcs) 

D\  S  h  Seres  <  Sikes 


ALG-TUPLE-RECSUB: 


for »  G  1 ...  n  we  have 

_ D;  S  h  nru  Sc...  Sc  nrmi  <  nkg  &  ...  &  nk ^ 

D;S\~  (nrn  *  ...  *  nr)n)  Sc...  Sc  (nrml  *  ...  *  nrmn)  < 
(nJbj j  *  ...  *  n4in)  &  ...  &  ( nkql  *  ...  *  nk^) 


Figure  3.7:  Algorithmic  Rules  for  Recursive  Subtyping 
The  proof  is  a  simple  induction  on  the  derivation  of  D;  S'  h  nr  <  nk. 

Fact  3.24  (Subtype  Eliminable  Assumptions)  If  D,{}  t-  Scnrcs  <  Scnkcs  and  D;S  U 
{(Scnrcs,  Scnkcs)}  h  nr  <  nk  then  D\  S  H  nr  <  nk. 

The  proof  is  by  induction  on  the  derivation  of  D\  S  U  {(&nres,  &nics)}  h  nr  <  nk. 

As  we  did  for  the  rules  for  emptyness,  we  must  define  a  universe  of  all  possible  members 
of  the  trail: 

Definition  3.25  Define  subtypeU(P)  to  be 

{(nr,/j£)  |  nr  G  emptyU (D)andnk  €  emptyU(D)}. 
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and  continue  with  separate  proofs  for  the  if  and  only  if  cases: 

Fact  3 .26  (Recursive  Subtype  Consistency  I) 

//  D  h  nr  <  nk  and  for  all  ( &nrcs,&nkcs )  €  S  we  have  D  I-  &nrcs  <  &nkcs  then 
D;  S  h  nr  <  nk. 

Proof  is  by  induction  on  the  pair  (subtypeU(D)  -  S,  depth(nr)),  ordered  lexicographi¬ 
cally. 

Fact  3.27  (Recursive  Subtype  Consistency  II)  If  D,  {}  \-  nr  <  nk  then  D  h  nr  <  nk. 

Proof  is  by  co-induction,  and  is  similar  to  the  proof  of  Theorem  3.20  (Emptyness 
Consistency  11)  on  page  190. 

An  analogue  for  Theorem  2.21  (Subtypes  Refine)  on  page  36  holds  for  recursive  types: 

Fact  3.28  (Recursive  Subtypes  Refine)  If  D  h  nr  <  nk  then  there  is  a  t  such  that  D  \- 
nr  dt  and  D  h  nk  Ct. 

Proof  is  by  induction  on  the  depth  of  nr. 

For  refinement  types,  we  explicitly  assumed  that  intersection  is  a  greatest  lower  bound. 
For  recursive  types,  we  must  prove  it.  The  proof  is  not  very  interesting;  it  is  included 
because  it  is  a  proof  about  recursive  subtyping  that  has  no  analog  in  Section  3.3. 

Lemma  3.29  (Recursive  Intersection  Lower  Bound)  IfD  \~  nr  <  nkand  D  H  nr&np  tz 
t  then  D  b  nr  &  np  <  nk. 

Proof:  By  co-induction.  Take  D  as  fixed,  and  let  F  be  an  encoding  of  the  declarative 
subtype  inference  system  in  Figure  3.6  as  a  function  from  sets  of  pairs  of  recursive  types  to 
sets  of  pairs  of  recursive  types.  Let 

Q  =  {(nr  &  np,  nk)  j  D  h  nr  <  nk  and  for  some  t  we  have  D\~  nr  fknptl  t}. 

Then  our  goal  is  to  show  Q  C  gfp(F),  and  by  co-induction,  it  suffices  to  show  Q  C  F(Q). 
Let  (nr  &  np,  nk)  be  any  element  of  Q\  if  we  can  show  (nr  &  np,  nk)  e  F(Q),  we  are 
done.  We  must  have  D  h  nr  &  np  C  t,  so  nr  must  have  one  of  the  following  forms: 

Case:  nr  oc  8cnrcs  Then  the  last  inference  of  0  1-  nr  <  nk  must  be  NEW-INFER-RECSUB, 
so  nib  a  &nkcs  and  the  premises  of  NEW-INFER-RECSUB  are 


D  h  &  nrcs  C  tc 
D  h  &  nkcs  C  tc 


3.4.  SUBTYPING 


197 


where  tc  is  new  and 

for  all  c  and  all  nr'  such  that  &nrcs  X  c(nr')  G  D 

either  D  h  nr'  empty  _  (3.5) 

or  there  is  a  nk'  such  that  &nkcs  X  c(nk')  G  D  and  D\-  nr'  <  nk' 

Let  c  and  np"  be  given  such  that  (&nrcs)  &  ( &npcs )  X  c(np")  G  D.  By  definition _of 
intersection  membership,  np"  «  nr'  &  np'  for  some  nr'  such  that  &nrcs  X  c(nr')  G  D. 
By  Fact  3.8  (Intersection  Refines)  on  page  179,  there  is  a  u  such  that 

D  f-  nr'  &  np'  C  u  (3.6) 


By  (3.5)  we  have  the  following  cases: 


SubCase:  D  I-  nr'  empty 
D  h  nr'  &  np'  empty. 


By  Theorem  3.22  (Empty  Intersection)  on  page  192  we  have 


SubCase:  otherwise 


Then  by  (3.5)  there  is  a  nk'  such  that  &nkcs  X  c(nk')  G  D  and 


D  h  nr'  <  nk'.  By  definition  of  Q,  this  implies  (nr'  &  np',  nk')  G  Q. 


End  SubCase 
Summarizing, 


for  all  c  and  all  np"  such  that  (&nrcs)  &  (&npcs)  X  c(np")  G  D  we  have 
either  D  h  np"  empty 

or  there  is  a  nk'  such  that  &nkcs  X  c(nk')  G  D  and  (np",  nk')  G  Q 


Thus  NEW-INFER-RECSUB  gives  ((&nrcs)  &  ( &npcs),nk )  G  F(Q),  which  is  what  we 
wanted  to  show. 


Case:  nr  oc  &{rj  — » nr<  |  t  G  1 . . .  n} 


Then  the  last  inference  of  D  b  nr  <  nk  is  arrow- 


RECSUB  and  nk  =  &{ki  -*  nki  \  i  G  1 . . .  m}.  The  premises  of  ARROW-SUB  include 


for  j  in  1 ...  m  we  have  D  h  &{nri  |  *  G  1 . . .  n  and  kj  <  r,}  <  nkj. 


The  last  inferences  of  D  \-  nr&np  [Zt  must  be  AND-RECREF1NES  and  arrow-recrefines 
so  np  <x  &{ri  — > nr,  \  i  G  n  +  \  ...q}  and  t  «  t\-*t2  and  the  premises  of  arrow- 
RECREFINES  are 

for  *  G  1 ...  q  we  have  rj  C  t\ 


and 


for  i  G  1 ...  q  we  have  D  nr^  c  42- 


Using  AND-REC REFINES  gives 


forj  G  1 ...  m  we  have  D  h  &  (nr,-  j  *  G  I . . .  q  and  kj  <  r,}  C  t2. 
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The  definition  of  Q  gives 

for  j  in  1 . .  .m  we  have  (&{nrj  1 1  G  1 . . .  q  and  kj  <  r*},  nkj)  G  Q 
and  then  ARROW-RECSUB  gives  (nr  &  np,  nk)  G  F(Q),  which  is  our  conclusion. 


Case:  nr  cx  &rcs 


Then  the  last  inference  of  D  b  nr  <  nJb  must  be  OLD-RECSUB,  where 


def  dcf  def 

nk  oc  &kcs  and  the  premise  of  OLD-RECSUB  is  ( A  res)  <  ( A  kcs).  The  last  inferences  of 
Dhnr&npCtare  AND-REC  REFINES  and  OLD-RECREFINES,  SO  np  a  &pca  and  t  cx  tc 
where  tc  is  old  and  the  premises  of  OLD-RECREFINES  include 

def 

for  rc  G  res  U  pcs  we  have  re  C  tc. 

def  def . 

By  Assumption  2.16  (A  defined)  on  page  34,  A  (res  U  pcs)  is  defined,  and  by  Assumption 

def  def.  ,  def  def  ,  ^ 

2.17  (A  Elim)  on  page  34  we  have  A  (res  U  pcs )  <  A  kca.  The  OLD-RECSUB  gives 

(dA  (res  U  pea),  A  kes)  G  Q,  which  is  our  conclusion. 


Case:  nr  oc  (nrM  *  ...  *  nri„)  &  ...  &  (nrmi  *  ...  *  nrm„) 


Then  the  last  inference  of 


D  b  nr  <  nfc  is  TUPLE-RECSUB,  so  nk  oc  (nku  *  . .  *  nk i„)  & ...  &  (nkq ,  *  ...  *  nk,^)  and 
the  premises  of  tuple-recsub  are 

for  *  G  1 ...  n  we  have  D  h  nru  & ...  &  nrmi  <  nkXi  & ...  &  nk 

The  last  inferences  of  D  H  nr  &  np  c  £  must  be  AND-RECREFINES  and  tuple-recrefines, 
so  t  oc  tx*...*  tn  and  np  oc  (nr(m+i)i  *...*  nr(m+i)n)  & ...  &  (nrzl  *  ...  *  nrin)  and  the 
premises  of  TUPLE-RECREFINES  must  be 

for  i  G  1 . . .  n  and  j  G  1 ...  z  we  have  D  b  nrji  □  U. 

AND-RECREFINES  then  gives 

for  i  G  1 ...  n  we  have  D  b  nru  &...&  nrz{  C  fj, 

and  the  definition  of  Q  then  gives 

for  t  G  1 ...  n  we  have  (nru  &  ...  &  nru,  nku  &  ...  &  nkqi)  G  Q- 


TUPLE-RECSUB  then  gives  (nr  &  np,  nk)  G  F(Q),  which  is  our  conclusion.  □ 

Intersection  is  also  a  greatest  lower  bound  for  recursive  types. 

Fact  330  (Recursive  Intersection  Greatest)  //  D  b  nr  <  nk  and  D  b  nr  <  np  then 
D  b  nr  <  nk  &  np. 
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The  proof  is  a  straightforward  co-induction,  and  we  omit  it. 

All  recursive  types  that  refine  some  ML  type  are  subtypes  of  themselves,  but  to  make 
the  co-induction  go  through  we  must  first  instead  prove  a  stronger  assertion: 

Lemma  3.31  (Self  Recsub)  If  D  t-  8c  nrs  C  t  then  for  any  nks  C  nrs  we  have  D  t-  Scnrs  < 
&nks. 


Proof:  By  co-induction.  Take  D  as  fixed  and  let  F  be  the  natural  encoding  of  the  inference 
rules  in  Figure  3.6  as  a  function  from  pairs  of  recursive  types  to  pairs  of  recursive  types. 
Let  Q  —  {(&nrs,&nits)  j  D  h  &  nrs  □  t  and  nks  C  nrs}.  Then  our  goal  is  to  show 
Q  C  gfp(F),  and  by  co-induction  it  suffices  to  show  Q  C  F(Q).  Proof  is  by  cases  on 
&nrs. 


The  most  natural  statement  of  this  theorem  would  only  allow  nrs  and  nks  to  be  identical, 
each  with  exactly  one  element.  The  case  for  arrow  types  required  strengthening  the  co¬ 
induction  hypothesis  to  include  the  possibility  that  nrs  contains  more  than  one  element. 
Once  we  allow  nrs  to  contain  more  than  one  element,  the  case  for  recursive  type  constructors 
required  including  the  possibility  that  nks  has  more  than  one  element. 


Case:  Scnrs  =  Scnrcs 


Then  &nks  oc  &nkcs.  Let  c  and  nr'  such  that  Scnrcs  y  c(nr')  E 


D  be  given.  By  definition  of  intersection  membership,  nr'  oc  &nrs',  and  there  is  a 
nks'  C  nrs'  such  that  &nkcs  >z  c(Scnks ')  €  D.  Definition  of  Q  gives  (Scnrs',  &nks')  E  Q. 
Summarizing  this  case  so  far  (and  adding  an  otherwise  unnecessary  disjunction  to  make  the 
summary  have  the  right  form). 


for  all  c  and  all  &nrs'  such  that  &nrcs  >z  c(&nrs')  E  D 
either  D  t-  &nrs'  empty 

or  there  is  a  Scnks'  such  that  &nkcs  X  c(Scnks')  €  D  and  D  h  &nrs'  <  &nks ' 


By  NEW-INFER-RECSUB,  this  implies  (&nrcs,&nkcs)  E  F(Q ),  which  is  what  we  wanted  to 
show. 


Case:  &nrs  oc  &{rj  — ►  nr;  |  z  €  1 . . .  n} 
where  m  <  n.  By  SELF-SUB  we  have 


Then  Scnks  oc  &{rj 


nr{ 


i  E  1  . . .  m} 


for  j  in  1 . . .  m  we  have  r7-  <  rj 

and  some  simple  set  manipulation  and  the  definition  of  Q  gives 

for  j  in  1 . . .  m  we  have  (&{nr  j  j  i  E  1 . . .  n  and  rj  <  r^},  nrf)  E  Q. 
ARROW-RECSUB  then  gives  (&nrs,  Scnks)  E  F(Q),  which  is  what  we  wanted  to  show. 


Case:  Scnrs  oc  8crcs 


Then  8cnks  oc  &kcs,  where  kcs  c  res.  Simple  reasoning  about  A 


gives  (A  res)  <  ( A  kcs),  and  by  OLD-RECSUB  this  implies  (Scnrs, Scnks)  E  Q,  which  is 
our  conclusion. 


200  CHAPTER  3.  DECLARING  REFINEMENTS  OF  RECURSIVE  DATA  TYPES 


Then  Scnks  oc  (nrn  *  ...  * 
definition  of  Q  give 

for  t  in  1 ...  n  we  have  (nr^  & . . .  &  nrmi ,  m*u  &  ...  &  nr^)  £  Q 

and  TUPLE-RECSUB  gives  ( Scnrs,  Scnks )  £  F(Q),  which  is  our  conclusion.  □ 

Now  we  can  move  on  to  prove  that  recursive  subtyping  is  transitive,  which  is  somewhat 
more  work.  Since  the  subtyping  rules  mention  emptyness,  we  need  to  first  show  that  a 
type  smaller  than  an  empty  type  is  also  empty.  Proving  this  requires  a  slightly  unusual 
co-induction;  we  include  the  case  of  the  proof  that  makes  the  unusualness  necessary: 

Theorem  332  (Empty  Transitivity)  If  D  nk  empty  and  D  nr  <  nk  then  D  f- 
nr  empty. 

Proof:  Take  D  as  fixed,  and  let  F  be  the  natural  encoding  of  the  rules  for  emptyness  in 
Figure  3.4  as  a  function  from  sets  of  recursive  types  to  sets  of  recursive  types.  Let  Q'  = 
{nr  |  there  is  a  nk  such  that  D  h  nk  empty  and  D  h  nr  <  nk},  and  let  Q  =  Q'  U  gfp(F). 
(This  definition  of  Q  allows  the  first  subcase  of  the  first  case  below  to  work.)  Our  theorem 
is  true  if  Q'  C  gfp(F),  which  is  true  if  and  only  if  Q  C  gfp(F).  By  co-induction  it  suffices 
to  show  Q  C  F(Q).  Proof  is  by  cases  on  some  nr  £  Q. 

If  nr  e  gfp(F),  then  by  definition  of  greatest  fixed  point,  nr  £  F(gfp(F)),  and  by 
monotonicity  of  F  we  have  nr  6  F(Q).  Thus  our  result  always  holds  if  nr  £  gfp(F),  and 
we  only  need  to  consider  nr  £  Q'  in  the  cases  below. 

Case:  nr  oc  Scnrcs  Then  the  last  inference  of  D  nr  <  nk  must  be  NEW-1NFER-RECSUB, 
so  nk  oc  Scnkcs  and  the  premises  of  NEW-INFER-RECSUB  are 

D  \~  8c  nrcs  E  tc 
D  h  &  nkcs  C  tc 

for  all  c  and  all  nr'  such  that  Scnrcs  y  c(nr')  €  D 

either  nr'  e  gfp(F)  _  (3.7) 

or  there  is  a  nk'  such  that  8cnkcs  y  c(nk')  6  D  and  D  nr1  <  nk1. 

The  last  inference  of  D  h  nk  empty  must  be  NEW-INFER-EMPTY  with  the  premise 

for  all  c  and  all  nk'  such  that  Scnkcs  y  c(nk')  e  D  we  have  D  h  nk’  empty  (3.8) 
and  by  NEW-INFER-EMPTY  it  suffic“s  to  show 

for  all  c  and  all  nr'  such  that  Scnrcs  y  c(nr')  €  D  we  have  nr'  €  Q 

Let  c  and  nr'  such  that  Scnrcs  y  c(nr')  £  D  be  given.  By  (3.7),  we  have  these  cases: 


Case:  nrs  oc  ( nrn  *  ...  *  nrJn)  & ...  &  (nr,i  *  ...  *  nr,*) 
nr in)  Sc ...  &  (nr^n)  where  q<m.  Set  manipulation  and  the 
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SubCase:  nr'  £  gfp(F)  Then,  by  definition  of  Q,  we  have  nr'  £  Q.  (This  is  the  step 
that  requires  Q  to  be  larger  than  Q'.) 

SubCase:  Otherwise  Then  there  is  a  nk'  such  that  &nkca  y  c(nk')  £  D  and  D  b  nr'  < 

nk'.  By  (3.8),  this  implies  D  I-  nk1  empty.  Definition  of  Q'  gives  nr'  £  Q',  and  then 
definition  of  Q  gives  nr'  £  Q. 

End  SubCase 

Summarizing  the  above  two  cases, 

for  all  c  and  all  nr'  such  that  &nrcs  y  c(nr')  £  D  we  have  nr'  £  Q 
NEW- infer -EMPTY  then  gives  &nrca  £  F(Q),  which  is  what  we  wanted  to  show. 

Case:  Otherwise  The  remaining  possibilities  are  all  straightforward  and  are  omitted.  □ 

Theorem  3.33  (Subtype  Transitivity)  If  D  b  nr  <  nk  and  D  b  nk  <  np  then  D  b  nr  < 
np. 

Proof:  By  co-induction.  Take  D  as  fixed,  and  let  F  be  the  encoding  of  the  recursive 
subtyping  relation  in  Figure  3.6  as  a  function  from  pairs  of  recursive  types  to  pairs  of 
recursive  types,  and  let 

Q  —  {(nr,  np)  |  for  some  nk  we  have  D  b  nr  <  nk  and  D  b  nk  <  np}. 

We  need  to  prove  Q  C  gfp(Z’),  and  by  co-induction  it  suffices  to  show  Q  c  F(Q).  Proof 
is  by  cases  on  an  nr  such  that  (nr,  np)  £  Q.  Delicate  use  of  the  fact  that  intersection  for 
recursive  types  is  a  least  upper  bound  is  necessary  in  the  case  where  nr  refines  an  arrow 
type. 

Case:  nr  oc  &nrcs  Let  nk  be  as  given  in  the  definition  of  Q.  Since  D  h  nr  <  nk,  by 
new-infer-recsub  we  have  nk  oc  &nkc3  and  the  following: 

D  h  &  nrcs  C  tc 

D  (-  &  nkcs  C  tc 

for  all  c  and  all  nr'  such  that  &nrcs  y  c(nr')  £  D 

either  D  h  nr'  empty  ,  (3.9) 

or  there  is  a  nk'  such  that  &nkca  >  c(nk')  £  and  D  h  nr'  <  nk'. 

Similarly,  since  D  h  nk  <  np,  by  NEW-INFER-RECSUB  we  know  np  oc  &npcs  and  the 
following: 


D  H  &  npca  C  tc 
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for  all  c  and  all  nk'  such  that  &nkca  >z  c(nk')  £  D 

either  D  h  nk'  empty  (3.10) 

or  there  is  a  np'  such  that  &npca  y  c(np')  and  D  h  nJe'  <  np' 

Our  goal  is  to  prove  (&n res,  &npcs)  £  F(Q),  and  by  NEW-INFER-RECSUB  it  suffices  to 
show 

for  all  c  and  all  nr'  such  that  &nrcs  y  c(nr')  £  D 

either  D  h  nr'  empty  _  (3.1 1) 

or  there  is  a  np '  such  that  &npca  >z  c(np')  £  D  and  (nr',  np')  £  Q 


To  prove  this,  let  c  and  nr'  such  that  &nrca  y  c(nr')  £  D  be  given.  By  (3.9),  either 
D  H  nr'  empty  (in  which  case  we  are  done)  or  there  is  a  nk'  such  that &nkcs  y  c(nk')  £  D 
and  D  h  nr'  <  nk' .  Applying  (3.10)  to  this  gives  two  cases: 


SubCase:  D  h  nk '  empty  Because  D  h  nr'  <  nk'.  Theorem  3.32  (Empty  Transitivity) 


on  page  200  gives  D  h  nr'  empty,  which  implies  (3.1 1). 


SubCase:  Otherwise 


Then  there  is  a  np'  such  that  &npca  y  c(np')  £  D  and  D  b  nk’  < 


np'.  The  definition  of  Q  then  gives  (nr',  np')  £  Q. 


End  SubCase 

Summarizing,  (3.1 1)  is  true  regardless.  By  NEW-INFER-RECSUB,  this  implies  our  conclusion. 


Case:  nr  oc  &{r*  — ►  m\  |  i  £  1 . . .  n} 


Then  the  last  inference  of  D  \-  nr  <  nk  must  be 

npz\  z  £ 


ARROW-RECSUB,  so  nk  oc  {kj  — *  nkj  \  j  £  1 . .  .m}  and,  similarly,  np  oc  {p, 

1 ...  q}.  The  premises  of  arrow-recsub  must  include 

D  H  &  {rj  —>  nr;  j  i  €  1 . . .  n}  Cl  t  (3-12) 

for  j  €  1 . .  .m  we  have  D  h  &{m\  | »  £  1 . .  .n  and  h,  <  r^}  <  nkj  (3.13) 

for  z  £  1 ...  q  we  have  D  h  8c{nkj  |  j  £  1 . . .  m  and  pz  <  kj}  <  npz  (3.14) 

By  the  form  of  nr,  we  must  have  t  <xt\—>  $2- 


By  repeated  use  of  Lemma  3.29  (Recursive  Intersection  Lower  Bound)  on  page  196 
with  (3.13)  we  have 

for  z  £  1 ...  q  and  j'  £  1 ...  m  we  have 
Pz  <  kj>  implies 

D  (-  &{&{nr,-  j  *  £  1  ...n  and  kj  <  r,}  |  j  £  1 . . . m  and p,  <  %}  <  nkj> 

t 

and  Fact  3.30  (Recursive  Intersection  Greatest)  on  page  198  then  gives 


for  z  £  1 ...  q  we  have 

D  &{&{nri  |  i  £  1 . . .  n  and  kj  <  r*}  |  j  £  1 . . .  m  and  p*  <  kj}  < 
&{niji  |  j'  £  1 . . .  m  and  p*  <  kj>}. 
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Set  manipulation  gives 

{&{nr\  I  i  G  1 . . .  n  and  kj  <  rj  |  j  G  1 . . .  m  and  pz  <  kj} 

{nrj  1 1  G  1 . . .  n  and  j  G  1 . . .  m  and  pz  <  kj  and  kj  <  rj. 

By  TRANS-SUBTYPE,  p,  <  kj  and  kj  <  r{  implies  px  <  r„  so 

{nr,  |  *  G  1 ...  n  and  j  G  l . . .  m  and  pz  <  kj  and  kj  <  rj} 

C 

{nrj  |  *  G  1 . . .  n  and  pz  <  rj}. 

Thus  Lemma  3.29  (Recursive  Intersection  Lower  Bound)  on  page  196  gives 


for  z  G  1 ...  q  we  have 

D  h  &{nrj  |  *  G  1 . . . n  and  pz  <  rj}  <  8c{nkj>  \  j'  G  1 . . .  m  and  pz  <  kj>} 
From  this,  (3.14),  and  the  definition  of  Q,  we  can  infer 

for  z  G  1 ...  q  we  have  (&{w\  j »  G  1 . . .  n  and  pz  <  *\},  npz)  G  Q , 


and  ARROW-RECSUB  then  gives  (nr,  np)  G  F(Q),  which  is  our  conclusion. 


Case:  nr  oc  Sens 


Then  the  last  inference  of  D  F  nr  <  ni  is  old  recsub  and  nk  tx 


def  def  def 

&kcs.  Similarly,  np  cx  Scpcs.  The  premises  of  OLD-RECSUB  are  (A  res)  <  (A  kes ). 

def  def  def  def  def  def 

and  ( A  Jfccs)  <  (A  pcs).  By  Assumption  2.14  (trans-<)  on  page  34  we  have  ( A  res)  < 

( A  pcs),  and  then  OLD-RECSUB  gives  (nr,  np)  G  F{Q),  which  is  our  conclusion. 


Case:  nr  a  (nru  *  ...  *  nri„)  &  ...  &  (nrmi  *  ...  *  nrmn) 


Then  the  last  inference  of 


D  I-  nr  <  nib  is  TUPLE-RECSUB,  SO  nib  oc  (nAn  *  ...  *  n*i„)  &  ...  &  ( nkql  *  ...  *  nAr^,). 
Similarly,  np  oc  (npu  *  ...  *  npln)  & ...  &  (npzl  *  ...  *  npzn)  and  the  premises  of  TUPLE- 
RECSUB  are 


for  i  G  1 ...  n  we  have  D  h  nru  &  ...  &  nrmi  <  nku  &...8c  nkqi 


and 

for  i  G  1 ... n  we  have  D  F  nku  8c...  Sc  nkqz  <  npu  &  ...  &  npzi. 

The  definition  of  Q  then  gives 

for  t  G  1 ... n  we  have  (nrjj  & ...  &  nrmi, npu  8c...  &  npzi )  G  Q, 

and  TUPLE-RECSUB  then  gives  (nr,  np)  G  F(Q),  which  is  our  conclusion.  □ 

Finally,  we  can  show  that  recursive  subtyping  is  sound: 
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Theorem  3 J4  (Recursive  Subtype  Soundness)  If  D  nr  <  nk  and  D  v  e  nr  then 
D  F  v  £  nk. 

Proof:  By  co-induction.  Take  D  to  be  fixed,  and  let  F  be  the  natural  encoding  of  the 
recursive  subtyping  relation  defined  in  Figure  3.6  as  a  function  from  pairs  of  recursive 
types  to  pairs  of  recursive  types,  and  let 

Q  =  {(«,  nk)  |  for  some  nr  we  have  D  F  nr  <  nk  and  D  F  v  £  nr}. 

We  want  to  show  Q  C  gfp(F),  and  by  co-induction  it  suffices  to  show  Q  C  F(Q).  Proof 
is  by  cases  on  a  (v,  nk)  £  Q.  The  proof  is  straightforward,  but  we  include  it  because  the 
result  is  important. 

Case:  nk  <x  &nks  where  nka  has  two  or  more  dements  Then  there  is  an  nr  such  that 
D  h  nr  <  &nka  and  D  F  t;  £  nr.  By  Lemma  3.31  (Self  Recsub)  on  page  199, 

for  all  nk'  £  nka  we  have  D  F  &nks  <  nk' 

and  by  Theorem  3.33  (Subtype  Transitivity)  on  page  201, 

for  all  nk'  £  nka  we  have  D  \~  nr  <  nk'. 

By  definition  of  Q,  this  implies 

for  all  nk'  £  nka  we  have  ( v ,  nk')  £  Q 

and  by  AND-RECVALUE  this  implies  ( v,&nka )  G  F(Q),  which  is  our  conclusion. 

Case:  nk  <x  k-*  nk'  Then  there  is  an  nr  such  that  D  h  nr  <  k-*nk'  and  D  F  v  G  nr. 

The  only  way  to  infer  the  first  of  these  is  by  using  ARROW-RECSUB,  so  nr  <x  &{ri  — ►  m\  | 
i  g  1 . . .  n}  and  the  premises  of  ARROW-RECSUB  are 

DF  &  {n  — ♦  nr{  \  i  £  1 . . .  n}  C  t 
and 

D  F  &{nr,-  |  i  £  1  ...n  and  k  <  r*}  <  nk'.  (3.15) 

The  last  inferences  of  D  F  v  G  nr  must  be  AND-RECVALUE  and  abs-RECVALUE,  sob  a 
f  n  x:u  =>  e  and  the  premises  of  abs-RECVALUE  are 

for  i  in  1 ...  n,  all  v',  and  all  v"  such  that 
•  F  v"  :  k  and 
(In  x:u  ->  e)  v"  =>■  v' 
we  have 

OFv'G  nrj 


(3.16) 
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We  want  to  show  ((fn  x:t  »>  e),k— *  nk')  G  F(Q).  We  can  only  infer  this  by  using 
ABS-RECVALUE  with  the  premise 

for  all  v1  and  v"  such  that 
•  I-  v"  :  k  and 

(in  x:t  =>  e)  v"  =>  v'  (3.17) 

we  have 
(«',  nk')  e  Q 


To  prove  this,  let  v'  and  v"  be  given  such  that  -  I -  v"  :  k  and  (f n  x:t  ~>  e)  v"  =»  v'. 
By  (3.16), 


if  *  6  1 . . .  n  and  k  <  r{  then  D  hw'6  nr,-, 


and  then  AND-RECVALUE  gives  D  H  v'  G  &{nr»  |  i  G  1  ...n  and  k  <  r^}.  Then  (3.15)  and 
the  definition  of  Q  imply  («',  nib')  G  Q.  Thus  (3.17)  is  true,  which  implies  our  conclusion. 


Case:  nk  cx  nkc 


The  last  inference  in  D  \-  nr  <  nk  must  be  NEW-iNFER-RECSUB  wher^ 


nr  oc  &nrcs  and  the  premises  of  NEW-INFER-RECSUB  are 


D  h  &  nrcs  Cl  tc 
D  h  nkc  C  tc 


for  all  c  and  all  nr'  such  that  &nrcs  >z  c(nr')  G  D 

either  D  h  nr '  empty  (3.18) 

or  there  is  a  nk'  such  that  nkc  X  c(nk')  6  D  and  D  h  nr'  <  nk'. 

The  last  inferences  of  D  v  €  nr  must  be  AND-RECVALUE  and  NEW-RC-RECVALUE  where 
v  cx  c  v'  and  the  premises  of  NEW- RC- REC VALUE  are 

for  all  nrc  €  nrcs  we  have  some  nr'nrc  such  that 
nrc  y  c(nr'Bre)  G  D  and 
Dhv'6  nr'nrt 


Let  np  =  &{nr'nn  |  nrc  €  nrcs}.  By  definition  of  intersection  membership,  &nrcs  y 
c(np)  G  D.  By  AND-RECVALUE,  D  h  v'  g  np.  By  Theorem  3.21  (Soundness  of  Empty) 
on  page  191,  we  cannot  have  D  b  np  empty,  so  (3.18)  implies  there  is  a  nk'  such  that 
nkc  y  c(nk')  G  D  and  D  h  np  <  nk'.  By  definition  of  Q,  this  implies  (u',  nk')  G  Q,  and 
NEW-RC-RECVALUE  then  gives  (c  v',  nkc)  g  F(Q),  which  is  what  we  wanted  to  show. 


Case:  nk  <x  kc 


Then  the  last  inference  of  D  h  nr  <  nk  is  OLD-RECSUB  where  nr  oc  &rcs 


and  the  premise  of  OLD-RECSUB  is  ( A  res)  <  kc.  The  last  inferences  of  D  h  r  G  nr  must 
be  OLD-RC-RECVALUE  and  AND-RECVALUE  with  the  premises 


for  rc  G  res  we  have 
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Simple  manipulation  of  refinement  types  then  gives  •  1-  v  :  A  res;  then  weaken-type  gives 
•l-»:  i fee  and  OLD-RC-RECVALUE  gives  (v,  kc)  6  F(Q),  which  is  our  conclusion. 


Case:  nk  <x  nk\*  ...*  nkn  Then  the  last  inference  of  D  (-  nr  <  nk  is  TUPLE-RECSUB 


and  nr  a  (nrn  * ...  *  nr\n)  & ...  &  (nrmi  * ...  *  nrmn)  and  the  premise  of  TUPLE-RECSUB 
is 


for  t  €  1 ...  n  we  have  D  (-  nru  &...«&  nrmj  <  nki. 

The  last  inferences  of  D  v  £  nk  must  be  AND-RECVALUE  and  TUPLE-RECVALUE  where 
u  oc  (ui,...  ,u„)  and  the  premises  of  TUPLE-RECVALUE  are 


for  *  G  1 . . .  n  and  j  e  1 ...  m  we  have  D  h  v*  €  nr,i. 


And-recvalue  gives 

for  i  €  1 ...  n  we  have  D  h  Vi  €  nrti  &  ...  &  nrmj. 

Then  the  definition  of  Q  gives 

for  i  €  1 ...  n  we  have  (t>i,  nki)  €  Q 

and  TUPLE-RECVALUE  then  gives  ((vj,...  ,vn)}nki  *  ...  *  nkn)  e  F(Q),  which  is  our 
conclusion.  n 


3.5  Splitting 


This  section  describes  a  type  inference  system  for  inferring  the  relation  x  from  an  abstract 
declaration. 

The  type  inference  rules  for  splitting  recursive  types  are  in  Figure  3.8.  The  x  operator 
used  in  the  TUPLE-RECSPLIT  rule  was  introduced  on  page  117.  The  ARROW-RECSPLIT  and 
TUPLE- RECSPLT  rules  are  straightforward;  we  shall  explain  the  other  two. 

The  main  idea  behind  the  NEW-RECSPLIT  rule  is,  wherever  the  type  &nrcs  has  the 
definition  c(nr),  there  nust  be  some  consistency  between  the  splits  of  nr  and  the  splits  of 
&nns.  One  way  to  understand  the  details  is  by  stepping  through  an  explanation  of  why  it 
is  sound.  Suppose  a  value  c  v  is  in  &nncs;  then  we  need  to  know  it  is  in  some  fragment 
&nkcs  of  &nnc5.  There  must  be  some  definition  c(nr)  of  &nrcs  such  that  v  is  in  nr.  Thus 
v  is  in  some  fragment  nk  of  nr.  If  there  is  some  definition  c(np)  of  &nkcs  such  that  np  is 
larger  than  nk,  then  we  know  that  v  is  in  np  and  c  v  is  in  Scnkcs. 

Another  way  to  understand  it  is  to  look  at  an  example.  If  we  take  the  datatype 
declaration 


datatype  bliat  -  cons  of  bool  *  blist  |  nil  of  runit 
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a  is  a  nonempty  set,  and 
for  all  nk  in  a  we  have  D  t-  nJfc  <  &nrca,  and 
for  all  c  and  nr  such  that  &nrcs  y  c(nr)  £  D 
there  is  an  a'  such  that 
NEW-RECSPLiT:  DNrxj' 

for  all  nk  £  a there  is  an  &nkca  £  a  and  a  np  such  that 
&nkca  y  c(np)  £  D 
D  h  nk  <  np 

D  b  &  nrca  x  a 


arrow-recsplit: 


D  h  — ►  nri  &  . . .  &  rn  — ►  nrn  x  {rj  — >  m*i  &  . . .  &  rn  — »  nrn} 


old-recsplit: 


def  def  def  rdef  .  _ 

rci  A  . . .  A  rcn  x  { A  rca  |  rca  £  a} 


D  h  nr\  &  nr„  x  {&rca  |  rca  £  a} 


TUPLE-RECSPUT: 


_ for  i  €  1 ... n  we  have  D  l~  nrH  nrmj  x  a, _ 

D  h  (nrn  *  ...  *  nrtn)  &  . . .  &  (nrmi  *  ...  *  nr  mn)  ^  aj  X  . .  .  X  an 


Figure  3.8:  Splitting  for  Recursive  Types  (Greatest  Fixed  Point) 
and  the  abstract  declaration 

D  =  {TWi#<  y  cons(T  *  T  iliMt ) 

Tiii,*  y  nil(  runit) 
bev  y  cons(T bool  *  bod) 
bev  y  nil (runit) 
bod  y  cons(T j ool  *  bev )}, 

we  can  infer  D  I-  T biut  x  {bev,  bod}.  The  root  inference  of  the  derivation  of  this  is 
NEW-RECSPLU  with  the  premises: 

{bev,  bod }  is  a  nonempty  set 
D  b  bev  <  T  bu,t 
D  b  bod  <  T  in,t 

D  b  T tool  *  T nut  x  {T *  bev,  T ^  *  bod} 
bev  y  cons(Tjw,/  *  bod)  £  D 
D  \~  T  beet  *  bod  <  T  bool  *  bod 
bod  y  cons(T bev)  £  D 
D  b  T  *  bev  <  T  boot  *  bev 
D  b  runit  x  {runit} 
bev  y  nil  (runit)  £  D 
D  b  runit  <  runit 
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Despite  the  lack  of  intuitiveness  of  this  rule,  it  seems  to  work  well  in  practice. 

A  previous  version  of  old-recsplit  simply  said 

def  def  def 
rci  A  ...  A  rc„  x  a 

D  1-  nri  &  . . .  &  nrn  x  a 

which  is  straightforward.  The  problem  with  this  definition  is  that  we  need  to  prove  an 
analogue  of  Lemma  2.43  (Split  Intersection)  on  page  54  for  recursive  types.  This  requires 
sometimes  having  intersections  of  recursive  types  as  fragments  of  recursive  types;  the 
previous  version  does  not  permit  this,  but  the  rule  as  stated  allows  it. 

It  is  not  clear  how  to  make  an  efficient  algorithm  for  this  inference  system.  The 
implementation  attempts  to  use  a  brute-force  search  to  find  the  principal  splits  directly;  I  do 
not  know  if  that  strategy  is  sound.  Roughly  speaking,  the  implementation  enumerates  all 
fixed  points  of  the  function  arising  from  this  inference  system  such  that  each  intersection 
of  recursive  type  constructors  has  exactly  one  split,  and  that  no  two  elements  of  that  split 
are  comparable.  A  fixed  point  that  contains  the  smallest  types  in  the  splits  is  chosen,  and 
we  assume  it  contains  principal  splits.  I  do  not  know  whether  there  will  always  be  a  fixed 
poini  with  the  least  types. 

We  can  show  if  a  value  is  in  a  recursive  type,  then  it  is  in  some  fragment  of  that  recursive 
type. 

Theorem  335  (Recursive  Split  Soundness)  If  D  h  nr  x  nks  and  D  b  v  e  nr  then  for 
some  nk  €  nks  we  have  Z>  I-  v  e  nk. 


Proof:  By  induction  on  v. 


Case:  v  ex.  c  v'  where  c  is  new 


Then  the  last  inferences  of  D  \-  v  e  nr  must  be  and- 


RECVALUE  and  NEW-RC-RECVALUE  so  nr  has  the  form  &nrcs  and  the  premises  of  new-rc- 
RECVALUE  are 

for  nrc  €  nrcs  we  have  nrc  y  c(nrnre)  6  D  (3-19) 


and 


for  nrc  6  nrcs  we  have  D  F*  v'  €  nrn„. 

The  last  inference  of  Z?  1-  nr  x  nks  must  be  NEW-RECSPLIT  with  the  premises 

nks  is  a  nonempty  set 
for  all  nk  €  kts  we  have  D  H  nk  <  Scnrcs 


(3.20) 


and  _ 

for  all  c  and  all  nr'  such  that  &nrcs  y  c(  nr')  €  D 

there  is  an  s'  such  that 
D  h  nr'  x  s' 

for  all  np'  e  s'  there  is  an  &nkcs  €  nks  and  a  np  such  that 
&nkcs  t,  c(np)  €  D 
D  h  np'  <  np 


(3.21) 
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Let  nr'  —  &{nrBfe  |  nrc  £  nrcs}.  Using  the  definition  of  intersection  membership  and 
(3.19)  gives  Scnrcs  y  c(nr')  £  D.  Thus  we  can  use  (3.21)  to  get  an  a'  such  that 

D  h  nr'  x  a' 

and 

for  all  np'  £  a'  there  is  an  &nkcs  £  nks  and  a  np  such  that 
&nkc8  y  c(np)  £  D  (3.22) 

D  h  np'  <  np. 

Using  AND-RECVALUE  on  (3.20)  gives  DN'G  nr',  so  our  induction  hypothesis  gives  a 
np'  €  a'  such  that  Dhs'e  np'.  Thus  (3.22)  gives  a  &nkca  £  nLs  and  a  np  such  that 
Scnkcs  y  c(np)  e  D  and  D  I-  np'  <  np.  Theorem  3.34  (Recursive  Subtype  Soundness)  on 
page  204  gives  D  I-  v'  £  np,  and  Fact  3.11  (Intersection  Value  Membership)  on  page  183 
then  gives  Dhc  v'  £  &nkca,  which  is  our  conclusion. 

The  remaining  cases  are  simple,  but  they  are  also  short,  so  we  include  them  for  com¬ 
pleteness. 

Then  the  last  inferences  of  D  h  u  £  nr  must  be  and-recvalue 

nr  oc  ri  — >  nrt  &  . . .  &  r„  — ►  nr„.  Thus  the  only  way  to  infer 
flhnrx  nks  is  by  using  ARROW-RECSPL1T  so  nks  =  {nr}  and  our  premise  D  h  nr  x  nks 
is  our  conclusion. 

Case:  v  <x  c  v'  where  c  is  old  Then  the  last  inferences  of  Z?  t~  u  £  nr  are  and-recvalue 
and  OLD-RC-RECVALUE  where  nr  oc  &rcs  and  the  premises  of  OLD-RC-RECVALUE  are 

for  nr  £  res  we  have  •  l-  c  v' :  rc. 

The  last  inference  of  D  I-  nr  x  nks  must  be  OLD-RECSPLIT  where  for  some  set  s  of 
sets  of  refinement  type  constructors,  kta  =  {&kcs  \  kes  £  a}  and  the  premise  of  OLD- 

.  <fcf  def  ,def  ,  .  ,  ,  ,  . 

RECSPLrr  is  A  res  x  { A  kes  \  kes  £  s}.  Simple  reasoning  about  refinement  types  gives 
•I -  c  v' :  &rcs  and  Theorem  2.69  (Splitting  Value  Types)  on  page  89  gives  a  &kcs  £  nks 

del 

such  that  •  h  c  v'  :  A  kes.  By  WEAKEN-TYPE,  OLD-RC-RECVALUE,  and  AND-RECVALUE  this 
implies  D  h  c  v'  £  &kcs,  which  is  our  conclusion. 

Case:  v  <x  (v\,  ...,  »»n)  Then  the  last  inferences  of  D  H  v  £  nr  must  me  and- 

RECVALUE  and  TUPLE- pvECVALUE  where  nr  oc  (nr\\  * . .  .*  nr\n)& . .  .&(nrml  *...*nrmn) 
and  the  premises  are 

for  t  €  1 ...  n  and  j  £  1 ...  m  we  have  D  h  Vi  £  nrji. 

The  last  inference  of  Z)  1-  nr  x  nks  must  be  TUPLE-RECSPLIT  where  nks  oc  x  . . .  x  an 
and  the  premises  of  TUPLE-RECSPLIT  are 

for  t  £  1 ...  n  we  have  D  h  nru  & . . .  nrmj  x 


Case:  v  oc  f n  x:t  =*>  e 
and  abs-recvalue  where 
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And-recvalue  gives 

for »  G  1 ...  n  we  have  D  h  t><  €  nru  &  ...  &  nrmj, 

and  then  our  induction  hypothesis  gives 

for  i  €  1 . . .  n  there  is  a  nii  G  ^  such  that  DI-»iG  nk <. 

TUPLE-RECVALUE  then  gives  D  h  (t>j ,  . . .,  un)  G  nk]  *  ...  *  nkn.  The  definition  of  x 
gives  nil  *  ...  *  nin  G  nis,  which  is  our  conclusion.  □ 

It  is  also  possible  to  show  that  intersection  interacts  with  splitting  in  a  natural  way. 
Compare  this  to  Lemma  2.43  (Split  Intersection)  on  page  54. 

Fact  336  (Recursive  Split  Intersection)  //Dhnrxa  and  D\-  nr  cl  and  D\-  nkCt, 
then  D  b  nr  &  nk  x  {np  &  nk  |  np  G  a}. 

Proof  of  this  is  a  straightforward  co-induction. 


3.6  Recursive  Types  provide  Refinement  Type  Construc¬ 
tors 

In  this  section  we  show  that  the  assumptions  made  in  Chapter  2  and  the  assumptions  made 

def 

about  empty  in  this  chapter  actually  hold  for  recursive  types  as  defined  in  this  chapter. 

In  Subsection  3.6.1,  we  define  the  operators  that  were  taken  as  predefined  in  Chapter  2 
in  terms  of  recursive  type  operations  defined  in  this  chapter.  Then  in  Subsection  3.6.2  we 
enumerate  the  assumptions  from  Chapter  2  and  prove  them.  Finally,  in  Subsection  3.6.3 
we  will  prove  a  grand  soundness  result  for  this  entire  chapter:  if  refinement  type  inference 
concludes  a  value  is  in  a  refinement  type,  then  it  is  also  in  the  corresponding  recursive  type. 


3.6.1  Defining  the  Primitives 


def  def  ^ef 

First  we  need  to  define  the  primitives  A,  <,  : ,  and  so  forth  in  terms  of  recursive  type 
inference  as  defined  in  this  chapter.  We  assume  at  this  point  that  there  is  some  specific 
abstract  declaration  D  we  are  adding  to  the  global  environment,  and  the  primitives  are 


being  expanded  to  include  the  new  declaration.  For  example,  we  expect  c  :  r  nr  to  be 
true  if  either  it  was  true  before  we  encountered  the  declaration  D,  or  c,  r  and  nr  satisfy  the 
definition  we  give  below. 


If  two  refinement  type  constructors  refine  the  same  ML  type  constructor,  then  by 

def  .  def  . 

Assumption  2.16  (A  defined)  on  page  34  their  intersection  (using  A)  is  a  refinement  type 
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constructor.  This  is  not  true  for  recursive  type  constructors,  so  we  cannot  simply  define 
the  new  refinement  type  constructors  to  be  the  new  recursive  type  constructors.  Instead, 
we  define  a  refinement  type  constructor  to  be  any  intersection  (using  &)  of  recursive  type 
constructors  that  all  refine  the  same  ML  type  constructor. 

We  can  easily  promote  this  way  to  construct  refinement  type  constructors  from  recursive 
type  constructors  to  a  way  to  construct  refinement  types  from  recursive  types.  However, 
since  we  consider  &  for  recursive  types  to  be  associative,  commutative,  and  idempotent, 
but  we  do  not  assume  the  same  for  A  for  refinement  types,  there  are  many  refinement  types 
corresponding  to  one  recursive  type.  For  example,  the  recursive  type  bem  &  bod.  &  T  nut 
corresponds  to  any  of  the  refinement  types 

bem  A  bod  A  T  nut  , 
bod  A  bem  A  (T nut  &  bem), 
bem  &  bod  8c  T  not , 

or  infinitely  many  others.  We  could  represent  this  as  a  one-to-many  relation  between 
recursive  types  and  refinement  types.  Instead,  we  will  represent  it  as  the  inverse  of  a 
many-to-one  function  rtort  from  /refinement  types  to  recursive  types.  (Hence  the  name 
rtort.)  Formally,  we  have  the  following  definition: 

Definition  337  Define  the  function  rtort  from  refinement  types  to  recursive  types  by  the 
recursion  equations 

rtort(ri  -*  r2)  =  rt  rtort(r2) 
rtort(ri  A  r2)  =  rtort(r! )  &  rtort(r2) 
rtort(  rc)  =  rc 
non(8cnrcs)  =  8cnrcs 

rtort(ri  *  . . .  *  rn)  =  rtort(ri)  *  ...  *  rtort(r„) 

It  is  very  straightforward  to  define  when  a  refinement  type  constructor  refines  an  ML 
type  constructor  in  terms  of  the  behavior  of  the  recursive  types: 

def 

Definition  338  We  say  8cnrcs  C  tc  if  D  f-  &  nrcs  C  tc. 

With  this  definition,  recursive  types  refine  ML  types  if  and  only  if  the  corresponding 
refinement  types  refine  the  same  ML  types: 

Fact  339  Under  the  assumptions  arising  from  D  we  have  r  □  t  if  and  only  if  D  \~ 
rtort(r)  (Z  t. 

Proof  of  this  is  by  induction  on  r. 

To  find  the  intersection  of  constructed  refinement  type  constructors,  we  take  the  inter¬ 
section  at  the  recursive  type  level: 
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Definition  3.40  We  say  &nrcs  A  Strikes  =  &(nrcs  U  nkcs)  whenever  there  is  a  t  such  that 
Oh  &  ( nrcs  U  nkcs )  C  t. 

The  definition  of  subtyping  refinement  type  constructors  in  terms  of  subtyping  recursive 
types  is  also  straightforward: 


def 

Definition  3.41  We  say  Stnrcs  <  Strikes  if  D  h  St  nrcs  <  Strikes. 

With  this  definition,  the  subtyping  relation  for  refinement  types  coincides  with  the  one 
for  recursive  types: 

Fact  3.42  (Refinement  and  Recursive  Subtyping  Equivalence)  We  have  D  h  rtort(r)  < 
rtort(ib)  if  and  only  if,  under  the  assumptions  arising  from  D,  we  have  r  <k. 

One  proof  of  this  takes  the  “if*  and  the  “only  if’  cases  separately.  To  prove  the  “if’ 
case,  use  Theorem  2.21  (Subtypes  Refine)  on  page  36  to  find  a  t  that  both  r  and  k  refine,  and 
proceed  by  induction  on  that  t.  To  prove  the  “only  if”  case,  we  use  Fact  3.28  (Recursive 
Subtypes  Refine)  on  page  196  to  find  a  t  that  both  rtort(r)  and  rtort(fc)  refine,  and  again 
proceed  by  induction  on  that  t. 

This  implies  that,  whenever  two  refinement  types  coerce  to  the  same  recursive  type, 
they  are  equivalent: 

Corollary  3.43  (Equivalence  rtort)  Ifnon(r)  =  rtort(fc)  and  r  \zt  and  k  c<  then  r  =  k. 

Proof:  By  Lemma  3.31  (Self  Recsub)  on  page  199,  D  t-  rtort(r)  <  rtort(fc),  and  Fact  3.42 
(Refinement  and  Recursive  Subtyping  Equivalence)  on  page  212  gives  r  <  k.  Similarly 
k  <  r,  and  together  these  imply  r  =  k.  □ 

This  can  be  used  to  show  that  recursive  splitting  and  refinement  type  splitting  are 
consistent: 

Fact  3.44  (Refinement  and  Recursive  Split  Consistency)  If  D  \-  rtort(r)  x  {rtort(fe)  | 
k  S  a}  and  rCt  then  r  x  3. 

The  proof  of  this  is  a  straightforward  induction  on  t. 

Whenever  we  have  Stnrcs  >z  c(rtort(r))  €  D,  we  can  say  that  c  d?f  r  *-»  Stnrcs. 
In  general,  the  converse  does  not  hold,  because  Assumption  2.52  (Constructor  Argument 
Strengthen)  on  page  67  and  Assumption  2.53  (Constructor  Result  Weaken)  on  page  67  place 
constraints  on  the  behavior  of  that  may  not  be  satisfied  by  our  abstract  declaration.  For 
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example,  in  the  presence  of  the  example  abstract  declaration  appearing  on  page  183,  these 
constraints  give 

cons  d?f  (T tni  *  (bev  &  bod))  <— >  bev 

def  def 

because  bev  y  cons(T*00i  *  bod)  G  D  and  (bev  &  bod)  <  bod.  Reasoning  about  : 
requires  first  defining  a  version  of  intersection  membership  that  allows  the  argument  to  the 
constructor  to  be  strengthened  and  the  result  to  be  weakened: 

Definition  3.45  (Weakened  Intersection  Membership)  We  define  D  to  contain  all  ele¬ 
ments  of  the  form  &nrcs  >  c(nr)  where  there  are  nk  and  nkcs  such  that  &nkcs  >z  c(nk)  G  D 
and  D  h  nr  <  nk  and  D  I-  &nkcs  <  &nrcs. 

This  relation  makes  a  natural  statement  about  membership  of  values  in  recursive  types: 

Fact  3.46  (Weakened  Intersection  Soundness)  If  &nrcs  >  c(nr)  G  D  and  D  h  v'  G  nr 
then  D  h  c  v'  G  8cnrcs. 

The  proof  is  little  more  than  two  uses  of  Theorem  3.34  (Recursive  Subtype  Soundness) 
on  page  204. 

We  can  sometimes  use  the  definition  of  recursive  subtyping  to  eliminate  one  of  the 
subtyping  assertions  in  the  definition  of  Weakened  Intersection  Membership: 

Lemma  3.47  (Weakened  Intersection  Simplification  I)  If  nrc  >  c(nr)  then  either  D  H 
nr  empty  or  there  is  a  nk  such  that  D  f-  nr  <  nk  and  nrc  y  c(nk)  G  D. 

Proof:  The  definition  of  weakened  intersection  gives  npcs  and  np  such  that 


&  npcs  >;  c(np)  G  D 

(3.23) 

D  h  nr  <  np 

(3.24) 

D  h  &npcs  <  nrc 

(3.25) 

The  last  inference  of  (3.25)  must  be  NEW-INFER-RECSUB  with  the  premise 

for  all  c  and  all  np'  such  that  8cnpcs  y  c(np')  G  D 
either  D  h  np'  empty 

or  there  is  a  nk  such  that  nrc  y  c(nk)  G  D  and  DY-  np'  <  nk 
Using  (3.23)  and  (3.25),  we  get 

either  D  h  np  empty 

or  there  is  a  nk  such  that  nrc  y  c(nk)  G  D  and  D\-  np  <  nk' 


(3.26) 
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If  D  h  np  empty,  then  Theorem  3.32  (Empty  Transitivity)  on  page  200  and  (3.24)  give 
D  h  nr  empty,  which  implies  our  conclusion. 

Otherwise,  let  nk  be  as  given  in  (3.26).  Thus  nrc  y  c(nfc)  €  D  and  D  \~  np  <  nk\ 
Theorem  3.33  (Subtype  Transitivity)  on  page  201  and  (3.24)  give  D  h  rc  <  nk.  These 
imply  our  conclusion.  □ 

We  can  also  do  the  same  simplification  if  we  replace  nrc  by  an  intersection  of  recursive 
type  constructors: 

Lemma  3.48  (Weakened  Intersection  Simplification  II)  If&nrcs  >  c(nr)  €  D  then  ei¬ 
ther  D\-  nr  empty  or  there  is  a  nk  such  that  D\-  nr  <nk  and  &nrcs  y  c(nk)  €  D. 


Proof:  By  Lemma  3.31  (Self  Recsub)  on  page  199, 


for  all  nrc  €  nrcs  we  have  D  1-  8cnrcs  <  nrc. 


By  definition  of  weakened  intersection,  &nrcs  >  c(nr)  e  D  implies  there  are  &nkcs  and 
nk  such  that 

&nkcs  t  c(nk)  6  D, 

D  h  &nkcs  <  &.nrca, 


and 


D  b  nr  <  nk. 

Theorem  3.33  (Subtype  Transitivity)  on  page  201  gives 

for  all  nrc  6  nrcs  we  have  D  H  &nkcs  <  nrc 


and  definition  of  weakened  intersection  then  gives 

for  all  nrc  £  nrcs  we  have  nrc  >  c (nr)  E  D. 

and  then  Lemma  3.47  (Weakened  Intersection  Simplification  I)  on  page  213  gives 

for  ail  nrc  E  nrcs,  either 
D  h  nr  empty 

or  there  is  a  nknre  such  that  (3.27 ) 

D  h  nr  <  nknre 
nrc  y  c(nknn )  €  D 


If  D  h  nr  empty,  we  are  done.  Otherwise  let  nk  =  &{nknre  |  nrc  6  nrcs}.  By  (3.27) 
and  the  definition  of  weakened  intersection,  we  have  &nrcs  y  c(nk)  e  D,  and  by  (3.27) 
and  Fact  3.30  (Recursive  Intersection  Greatest)  on  page  198  we  have  D\~  nr  <  nk.  These 
last  two  are  our  conclusion.  □ 

We  can  define  d*f  in  terms  of  this.  To  make  Assumption  2.50  (Split  Constructor  Consis¬ 
tent)  on  page  66  hold,  we  need  to  also  say  that  c  d?f  r  <— ►  rc  whenever  r  is  empty;  see  the 
counterexample  that  arises  if  we  do  not  assume  this  in  the  discussion  of  Split  Constructor 
Consistent  on  page  217. 
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Definition  3.49  We  say  c  :  r  <—>  Scares  if  either  Scares  >  c(rtort(r))  £  D,  or  all  of  the 
following  hold: 

D  h  rtort(r)  empty 


aadfor  some  t  aad  tc  we  have 


def 

c  :  :  t  <->  tc , 

D  \~  Sc  arcs  C  fc, 


and 

D  h  rtort(r)  d  t. 


We  define  empty  in  terms  of  emptyness  for  recursive  types: 

def 

Definition  3 JO  We  say  Scares  empty  if  D  H  Scares  empty. 

Finally,  we  define  splitting  for  constructed  refinement  type  constructors  in  terms  of 
splitting  for  recursive  types: 

Definition  3.51  If  D  F  &  arcs  x  s,  then  we  say  Scares  *x  {Scnkcs  \  Scnkcs  £  a}. 

With  these  assumptions,  refinement  type  emptyness  and  recursive  type  emptyness  co¬ 
incide: 

Fact  3.52  (Emptyness  Consistency)  If  D  F  rtort(r)  empty  then  under  the  assumptions 
introduced  by  D  we  have  F  r  empty. 

The  proof  is  by  induction  on  depth(rtort(r)). 


3.6.2  Proving  the  Assumptions 

In  this  subsection  we  enumerate  the  assumptions  made  in  Chapter  2  about  predefined 
properties  of  refinement  type  constructors,  and  prove  that  they  hold  for  refinement  type 
constructors  derived  from  recursive  types  as  described  in  this  chapter.  This  is  only  non¬ 
trivial  for  Split  Constructor  Consistent,  which  is  discussed  on  page  217. 

Some  assumptions  are  not  addressed  in  this  list  because  they  concern  only  ML  type 
inference,  which  for  the  purposes  of  this  thesis  we  assume  is  well-understood.  We  include 
them  in  the  list  with  the  statement  that  the  assumption  is  entirely  about  ML  types. 

Assumption  2.2  (Constructors  have  Unique  ML  Types)  on  page  26:  For  each  c,  there 
are  unique  t  and  tc  such  that 
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This  is  entirely  about  ML  types. 

Assumption  2.7  (Unique  Predefined  Refinements)  on  page  31:  For  all  rc  there  is  a 

,  ,  def 

unique  tc  such  that  re  C  tc. 

Proof:  If  rc  is  old,  this  follows  from  Unique  Predefined  Refinements  before  we  incorporated 
D  into  the  environment. 

Otherwise,  rc  is  new  and  has  the  form  &nrcs  where  there  is  a  tc  such  that  D  F  &  nrcs  C 
tc.  Thus  there  is  at  least  one  re  C  tc. 

To  show  there  is  at  most  one,  suppose  D  t-  &  nrcs  c  tc  and  D  F  &  nrcs  C  tc'. 
Let  nrc  be  any  element  of  nrcs.  By  AND-RECREFINES  we  must  have  D  1-  nrc  c  tc  and 
D  h  nrc  c  tc '.  The  last  inference  of  these  must  be  NEW-RECREFINES  with  the  premises 

for  all  c  and  nr  such  that  nrc  X  c(nr)  €  D 

there  is  a  t  such  that  c  ::  t  ^  tc 
for  all  c  and  nr  such  that  nrc  X  c(nr)  €  D 

there  is  a  t  such  that  c  ::  t  <— ►  tc' 

By  Condition  3.2  (New  Recursive  Type  Constructors  Defined)  on  page  178  these  universal 
quantifications  are  not  vacuous,  so  by  Assumption  2.2  (Constructors  have  Unique  ML 
Types)  on  page  26,  tc  =  tc'.  □ 

Assumption  2.8  (Finite  Predefined  Refinements)  on  page  3 1 :  Immediate  from  Condition 
3.6  (Declarations  are  Finite)  on  page  179. 

def 

Assumption  2.13  (reflex- <)  on  page  33:  Immediate  from  Lemma  3.31  (Self  Recsub) 
on  page  199. 

def 

Assumption  2.14  (trans-<)  on  page  34:  Immediate  from  Theorem  3.33  (Subtype  Tran¬ 
sitivity)  on  page  201. 

def 

Assumption  2.15  (Refines  <)  on  page  34:  Immediate  from  Fact  3.28  (Recursive  Sub- 
types  Refine)  on  page  196  and  Fact  3.9  (Recursive  Unique  ML  Types)  on  page  179. 

.  def 

Assumption  2.16  ( A  defined)  on  page  34:  Immediate  from  the  definition  of  refinement 
type  constructors. 

def 

Assumption  2.17  (A  Elim)  on  page  34:  Immediate  from  Lemma  3.31  (Self  Recsub)  on 
page  199. 

def 

Assumption  2.18  (and-intro-<)  on  page  34:  Immediate  from  Fact  3.30  (Recursive 
Intersection  Greatest)  on  page  198. 

Assumption  2.30  (Split  Subtype  Consistent)  on  page  49:  Immediate  from  the  second 
premise  of  new-recsplit. 
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Assumption  2.36  (Refinement  Constructor  Splits  are  Nonempty)  on  page  5 1 :  Immediate 
from  the  first  premise  of  NEW-RECSPLrr. 

Assumption  2.42  (Predefined  Split  Intersection)  on  page  54:  Immediate  from  Fact  3.36 
(Recursive  Split  Intersection)  on  page  210. 

Assumption  2.49  (Constructor  Type  Refines)  on  page  65:  Straightforward  from  Fact 
3.28  (Recursive  Subtypes  Refine)  on  page  196. 

Assumption  2.50  (Split  Constructor  Consistent)  on  page  66:  If 

def 

c  :  t  ' — >  rc 


and 


def 

rc  x 


{rcj,  ...,rcn} 


then  there  is  some  provable  assertion  of  the  form 


r  x  {n,...,rm} 


such  that  for  all  j  between  1  and  m  there  is  an  i  between  1  and  n  such  that 


def 

c  :  r j  «— »  rci. 


If  instead  we  defined  c  :  r  <-*  &nrca  to  mean  &nrcs  >  c(rtort(r))  G  D,  this  would 
not  be  true.  A  counterexample  presumes  the  datatype  declaration 

datatype  d  -  a  of  tunit  |  b  of  tunit  |  c  of  d 
and  the  abstract  declaration 

D  =  {em  t  bottom(d), 
neml  y  a(rumf), 
neml  y  b(run*f), 
nem2  >  a(runit), 
nem2  >z  c (em), 
nemS  >z  a(runil), 
nem4  y  b(r,umt)}. 

The  names  em  and  nem  stand  for  “empty”  and  “nonempty”,  respectively.  Because 
D  f-  neml  <  nem2,  we  have  neml  >  c (em)  G  D.  We  also  have  D  h  neml  x 
{ nemS ,  nem4  },  so  Split  Constructor  Consistent  would  give  a  split  of  em  where  c  maps 
each  fragment  to  either  emS  or  em^ .  Since  the  fragments  must  all  be  subtypes  of  em,  the 
only  possible  split  is  {em}^  If  we  had  the  simpler  definition  of  d;f,  this  would  imply  that 
either  nem3  >  c (em)  €  D  or  nem4  >  c (em)  G  D,  neither  of  which  is  true.  With  the 
actual  definition  of  d?f,  we  have  both  c  df  em  <— ►  nem3  and  c  df  em  nem4 .  In  fact,  we 
can  prove  that  Split  Constructor  Consistent  is  true  in  general  for  the  actual  definition  of  ? . 
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Proof:  We  must  have  nr  cx^&nrca.  By  definition  of  : ,  either  D  I-  rtort(r)  empty 
or  &nrcs  >  c(rtort(r))  G  D.  In  the  latter  case,  Lemma  3.48  (Weakened  Intersection 
Simplification  II)  on  page  214  gives 

either  D  t-  rtort(r)  empty 
or  there  is  a  nk  such  that 
D  F  rtort(r)  <  nk 
&nrca  X  c(nk)  G  D. 

If  D  F  rtort(r)  empty,  by  SELF-SPLIT  we  can  choose  a  =  {r}.  Let  kc  be  any  element  of 
sc;  then  the  definition  of  df  immediately  gives  c  r  «-»  kc,  which  is  our  conclusion. 

Otherwise,  there  is  a  nk  such  that  D  F  rtort(r)  <  nk  and  &nrcs  X  c(nk)  G  D.  If  we 
let  sc'  =  (rtort(p)  |  p  G  sc}  the  definition  of  xf  gives  D  F  &  nrcs  x  sc';  the  last  inference 
of  this  must  be  NEW-RECSPLrr  with  the  premises 

sc'  is  a  nonempty  set, 

for  all  np  G  sc'  we  have  D  F  np  <  &nrcs , 

and  _ 

for  all  c  and  nk  such  that  &nrcs  X  c(np)  G  D 

there  is  an  s'  such  that 
Dhnix  s',  and 

for  all  np  in  s'  there  is  an  &nkca  G  sc'  and  a  nq  such  that 
Scnkcs  X  c(nq)  G  D,  and 
D  \~  np  <  nq. 

Applying  the  last  of  these  to  nk  and  c  gives  an  s'  such  that 

D  F  nk  x  s' 


and 

for  all  np  in  s'  there  is  an  &nkcs  G  sc'  and  a  ng  such  that 

&nkca  y  c(nq)  G  D,  and  (3.28) 

D  h  np  <  ng. 

By  Fact  3.36  (Recursive  Split  Intersection)  on  page  210, 

D  h  nk  &rtort(r)  x  {np  &rtort(r)  |  np  G  s'}. 

Lets  =  {p&r  |  rtort(p)  G  s'}.  By  Fact  3.44  (Refinement  and  Recursive  Split  Consistency) 
on  page  212,  if  we  choose  p  such  that  nk  =  rtort(p),  we  have  p  &  r  x  s.  Since  D  F 
rtort(r)  <  nk,  we  have  p&r  =  r,  so  EQUIV-SPLIT-L  gives  r  x  s. 

Let  A  G  s  be  given;  thus  A  a  p&r  where rtort(p)  G  s'.  By  (3.28),  there  is  an &nkcs  G  sc' 
and  a  ng  such  that &nkcs  X  c(nq)  g  £)  and  D  h  rtort(p)  <  nq.  By  Lemma  3.29  (Recursive 
Intersection  Lower  Bound)  on  page  196,  this  implies  D  F  rtort(p)  &  rtort(r)  <  nq,  and 
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the  definition  of  rtort  immediately  gives  D  b  rtort(fc)  <  nq.  The  definition  of  weakened 
intersection  then  gives 

Scnkca  >  c(rtort(fc))  G  D 

and  the  definition  of  d'f  gives  c  d?f  k  •—*  &nkca.  Since  &nkcs  G  sc',  Ankcs  is  in  sc,  so  this 
is  our  conclusion.  D 

Assumption  2.51  (Constructor  And  Introduction)  on  page  67:  If  c  r  «->  re  and 

def  .  ,  def  ,  def  . 

c  :  r  kc  then  c  :  r  <—*  (rc  A  kc). 

Proof:  The  proof  is  very  straightforward  despite  its  length  and  may  be  skipped  on  the  first 
reading. 

If  c  is  old,  then  Constructor  And  Introduction  continues  to  be  true  for  it  as  it  was  before 
we  added  the  declaration  D. 

If  we  infer  either  of  our  hypotheses  because  D  b  rtort(r)  empty,  then  the  definition  of 
d?f  gives  our  conclusion  immediately. 

Otherwise,  rc  oc  &nrcs  and  kc  «  &nkcs  and  by  the  definition  of  d*f  we  have  &nrcs  > 
c(rtort(r))  €  D  and  &nkcs  >  c(rtort(r))  €  D.  By  definition  of  weakened  intersection, 
there  are  np{,  npcsv  np2,  and  npcs2  such  that  all  of  the  following  are  true: 

&npcsl  >z  c(np,)  €  D 
D  I-  rtort(r)  <  np, 

D  h  &npcsx  <  &nrcs 
&npcs2  >z  c(np2)  £  D 
D  b  rtort(r)  <  np2 
D  h  &npcs2  <  &nkcs. 

The  definition  of  intersection  membership  gives 

&(npcs,  U  npcs2 )  >z  c(np1  &  np2)  G  D. 

Fact  3.30  (Recursive  Intersection  Greatest)  on  page  198  gives 

D  b  rtort(r)  <  npx  &  np2 

and  Lemma  3.29  (Recursive  Intersection  Lower  Bound)  on  page  196  gives 

D  (-  &.{npcsx  U  npcs2)  <  8cnrcs 
and 

D  b  &(npcs1  U  npcs2)  <  &nkcs 

and  Fact  3.30  (Recursive  Intersection  Greatest)  on  page  198  then  gives 


D  b  &(npcs}  U  npca2 )  <  &(nrcs  U  nkes). 
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Finally  the  definition  of  weakened  intersection  then  gives 

&(nrcs  U  nJbcs)  >  c(rtort(r)) 


and  the  definitions  of  :  and  A  give  c  :  r  <—*  rc  A  kc,  which  is  our  conclusion.  □ 

Assumption  2.52  (Constructor  Argument  Strengthen)  on  page  67:  If  c  r  «->  rc  and 
k  <  r  then  cdf  k  <— ►  rc. 

Proof:  If  we  inferred  c  r  rc  because  D  t-  rtort(r)  empty,  then  Theorem  3.32 
(Empty  Transitivity)  on  page  200  gives  D  b  rtort(fc)  empty,  and  our  conclusion  follows 
immediately.  Otherwise  our  conclusion  follows  from  Theorem  3.33  (Subtype  Transitivity) 
on  page  201.  □ 

Assumption  2.53  (Constructor  Result  Weaken)  on  page  67:  If  c  d?f  r  <—►  rc  and  rc  <  kc, 
then  cdf  r  <— ►  kc. 

Proof:  If  we  can  infer  c  d?f  r  >  rc  because  D  h  rtort(r)  empty,  then  we  get  our  conclusion 
immediately.  Otherwise  it  follows  from  Theorem  3.33  (Subtype  Transitivity)  on  page  201. 
□ 


Assumption  3.12  (Empty ness  Constructor)  on  page  184:  If  rc  empty  and  c  :  r  <—*  rc 
then  b  r  empty. 

Proof:  By  definition  of  c'f  r^re,  either  D  b  rtort(r)  empty  orrtort(rc)  >  c(rtort(r))  £ 
D.  If  the  former  is  true,  then  Fact  3.52  (Emptyness  Consistency)  on  page  215  gives  our 
conclusion.  Otherwise  the  statement  of  NEW-INFER-EMPTY,  two  uses  of  Theorem  3.32 
(Empty  Transitivity)  on  page  200,  and  Fact  3.52  (Emptyness  Consistency)  on  page  215 
give  our  conclusion.  □ 

def  def 

Assumption  3.13  (Emptyness  Subtyping)  on  page  185:  If  rc  empty  and  kc  <  rc  then 

def 

kc  empty.  Immediate  from  Theorem  3.32  (Empty  Transitivity)  on  page  200. 


3.6.3  Value  Containment 

Here  we  will  show  that  if  a  value  has  a  refinement  type,  it  has  the  corresponding  recursive 
type. 

Theorem  3.53  (Value  Containment)  Under  the  assumptions  introduced  by  D,  if  •  b  v  :  r 
then  D  b  v  £  rtort(r). 

Proof:  Take  D  as  given,  and  let  F  be  the  natural  encoding  of  the  rules  for  recursive  type 
membership  in  Figure  3.2  as  a  function,  and  let  Q  =  {(u,rtort(r))  |  •  b  v  :  r}.  We  need  to 
show  Q  C  gfp(F)  and  by  co-induction  it  suffices  to  show  Q  C  F(Q).  Proof  is  by  cases  on 
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a  pair  (v,r)  in  Q.  The  proof  is  straightforward  and  is  included  only  because  the  result  is 
important. 


Case:  r  oc  rt  &  r2  Then  rtort(r)  =  rtort(ri )  &  rtort(r2).  We  can  use  WEAKEN-TYPE  and 


b  v  :  r  to  infer  •  b  v  :  ri  and  •  b  v  :  r2.  Thus,  by  definition  of  Q,  we  have 


(u,rtort(r]))  G  Q 


and 

(v,rtort(r2))  G  Q. 

Then  and-recvalue  gives  (w,rtort(ri)  &  rtort(r2))  G  F(Q),  which  is  what  we  wanted  to 
show. 


Case:  vocc  v',  c  is  new,  and  r  oc  nrc 


and  ‘ho:  nrc  we  have 


By  Lemma  2.68  (Subtype  Irrelevancy)  on  page  88 
hb  v  :  nrc. 


The  last  inference  of  this  must  be  CONSTR-TYPE  with  the  premises 

def  , 

c  :  k  i — ►  nrc 


(3.29) 


If  we  were  able  to  infer  (3.29)  because  D  H  rtort(fc)  empty.  Fact  3.52  (Emptyness  Con¬ 
sistency)  on  page  215  gives  h  k  empty,  and  Fact  3.14  (Soundness  of  Refinement  Type 
Empty)  on  page  185  contradicts  -  I -  v'  :  k.  Thus  we  must  have  inferred  (3.29)  from 
nrc  >  c(rtort(fc)).  By  Lemma  3.47  (Weakened  Intersection  Simplification  I)  on  page  213, 
either  D  h  rtort(fc)  empty  or  there  is  a  np  such  that 


D  b  rtort(fe)  <  np 


and 


nrc  >:  c(np)  G  D. 


We  have  already  show  that  D  b  rtort(fc)  empty  cannot  be  true.  Thus  the  other  branch  of  the 
disjunction  is  true,  so  we  can  choose  a  p  such  that  rtort(p)  =  np.  By  Fact  3.42  (Refinement 
and  Recursive  Subtyping  Equivalence)  on  page  2 12  we  have  k  <  p,  and  then  weaken-type 
gives  •  b  v' :  p.  Thus  by  definition  of  Q  we  have  (r/,rtort(p))  G  Q,  and  NEW-RC-RECVALUE 
then  gives  (c  v\  nrc )  G  F{Q),  which  is  our  conclusion. 

Case:  v  <x  c  v',  c  is  new,  r  oc  Scnrcs  where  nrcs  has  two  or  more  elements. 
Weaken-type  immediately  gives 


for  all  nrc  G  nrca  we  have  •  b  v  :  &{nrc}. 
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Then  the  definition  of  Q  gives 

for  all  nrc  E  nrca  we  have  (v,  nrc)  E  Q 

and  AND-RECVALUE  then  gives  (o,&nrca)  E  F(Q),  which  is  our  conclusion. 

Case:  v  «  c  v\  c  is  old,  rotre  Then  we  can  immediately  use  OLD-RC-RECVALUE  to  get 
(t>,  re)  E  F(Q),  which  is  our  conclusion. 

Case:  v«ln  x:t  =>  e  and r  a  j*i  — ♦  r2  Suppose •  h  v"  :  rj  and (fn  x:t  ®>  e )  v"  => 

Then,  by  APPL-TYPE,  we  have  •  H  (fn  x:t  =>  e)  v"  :  r2,  and  by  Theorem  2.71 
(Refinement  Type  Soundness)  on  page  99  we  have  ■  h  v'  :  r2.  The  definition  of  Q  then 
gives  (u',rtort(r2))  E  Q. 

Thus,  by  abs-RECVALUE  we  have  ((fn  x:t  ->  e),  nr  — >rtort(r2))  E  F(Q).  By  defi¬ 
nition  of  rtort,  this  is  our  conclusion. 

By  Lemma  2.68  (Subtype  Irrelevancy) 
*  r„.  The  last  inference  of  this  must  be 

for  i  in  l . . .  n  we  have  •  I-  Vi :  ri. 

By  definition  of  Q  this  implies 

for  *  in  1 ...  n  we  have  (i\,rtort(r\))  E  Q, 

v„),rtort(r))  E  F(Q),  which 

□ 


Case:  v  <x  (t?i ,  ...»  vn)  and  r  cx  r\  *  ...  *  rn 

on  page  88  we  have  •  H-  (vt ,  ...,  vn)  :  r,  *  ... 
TUPLE-TYPE  with  the  premises 


and  the  definition  of  rtort  and  tuple-RECSUB  give  ((vi ,  . . . , 
is  our  conclusion. 


Chapter  4 

Refinement  Type  Variables 


There  are  two  changes  that  need  to  be  made  to  add  polymorphism  to  refinement  types.  We 
need  to  add  type  variables  and  refinement  type  constructors  that  take  type  arguments.  This 
chapter  discusses  the  former,  and  Chapter  5  discusses  the  latter. 

Adding  the  type  variables  is  fairly  simple.  After  looking  at  the  various  plausible  options 
in  Section  4. 1 ,  we  will  conclude  that  it  seems  best  for  each  ML  type  variable  to  have  exactly 
one  refinement,  which  is  a  refinement  type  variable.  Then  in  Section  4.2  we  will  describe 
the  changes  we  must  make  to  the  machinery  in  Chapters  2  and  3  to  accommodate  this. 


4.1  Adding  Type  Variables 

The  motivating  examples  behind  refinement  types  have  not  made  interesting  use  of  poly¬ 
morphism  so  far.  Since  ML  is  indeed  a  polymorphic  language,  we  need  a  straightforward 
correct  way  to  deal  with  polymorphism.  For  some  examples,  the  desired  behavior  is  clear. 
For  instance,  since  true  has  the  refinement  type  tt  and  false  has  the  refinement  type  ff, 
we  would  like  the  statement 

let  val  id  =  fn  x  =>  x 
in 

(id  true,  id  false) 

end 

to  get  the  refinement  type  tt  *  ff. 

Notation  to  represent  the  type  for  id  seems  straightforward.  The  most  general  ML  type 
scheme  for  id  is  written  as 

V(a).a— >a 

By  analogy  with  the  notation  for  the  ML  type  scheme,  we  shall  also  write  the  refinement 
type  scheme  as 

V(a).a  — »a. 
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4.1.1  Instantiation 

Next  we  need  to  understand  how  to  instantiate  the  refinement  type.  Instantiating  the  ML 
type  is  simple;  ML  type  inference  tells  us  that  in  this  example  the  a  in  the  ML  type  scheme 
should  be  instantiated  to  bool,  giving  a  resulting  type  of  bool  —*  bool.  Instantiating  the 
refinement  type  scheme  is  a  little  more  complex  because  it  must  have  both  of  the  types 
tt  — >  tt  and  ff  -*  ff.  We  could  take  the  path  used  in  [Pie91a)  and  instantiate  the  refinement 
type  scheme  to  a  list  of  refinement  types  that  is  explicitly  given  in  the  expression;  in  this  case 
we  would  be  instantiating  the  a  in  V(a).a  -*  a  to  {tt,  ff}  to  get  the  type  tt  — » tt  A  ff  -» ff. 
However,  we  know  that  all  of  the  types  in  the  list  must  be  refinements  of  bool,  and  since 
bool  has  finitely  many  refinements,  we  can  put  all  of  those  refinements  into  the  list.  We 
might  as  well  put  all  possible  refinements  into  the  list  since  that  will  yield  the  most  precise 
possible  result;  since  there  is  therefore  only  one  reasonable  list,  we  can  omit  the  list  instead 
of  explicitly  specifying  it. 

Thus,  to  instantiate  a  refinement  type  scheme,  we  instantiate  each  refinement  type 
variable  to  an  ML  type.  The  result  is  the  intersection  of  all  distinct  results  of  substituting 
refinements  of  that  ML  type  for  the  refinement  type  variable.  For  example,  instantiating 
the  refinement  type  variable  a  to  bool  in  the  refinement  type  scheme  V(a).a  — ►  a  yields 

tt  *  tt  A  ff  *  ff  A  T  io0i  ►  Tj^/A  -1 -bool  *  -Lio«  / 

Once  we  move  on  to  more  complex  examples,  more  choices  arise.  Consider  the 
expression  skeleton: 

let  val  strictif  *  fn  x  =>  fn  y  =>  fn  z  =>  if  x  then  y  else  z 
in 

end 

What  should  be  the  refinement  type  scheme  for  strictif?  The  ML  scheme  is 

V[a).bool  — ►  o.  — >  a  — ►  ol. 

It  is  tempting  to  permit  multiple  refinements  of  each  ML  type  variable,  since  we  could  give 
this  expression  an  informative  type  scheme  like 

V(a,/3).if  — *  a  — *  ft  — ►  a  A 

ff  -» a  -» (3  0  A 

T  bool  — *  oi  — >a  — >  Ol  A 
-1-4 ool  *  O!  >  Ol  *  -La 

Unfortunately,  if  we  permit  arbitrarily  many  refinements  of  each  ML  type  variable,  then 
there  are  expressions  with  no  principal  type.  We  will  illustrate  this  with  an  example. 

In  the  example,  we  shall  use  the  datatype 
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datatype  a  option  =  SOME  of  a  I  NOME 

to  represent  a  value  which  may  or  may  not  be  present.  Note  that  NONE  has  no  argument; 
we  are  using  the  concise  version  of  the  syntax  for  this  example.  We  want  to  distinguish 
the  two  constructors  of  this  datatype  at  the  refinement  type  level,  so  we  use  the  following 
rectype  statement: 


rectype  a  some  =  SOME  (a) 
and  a  none  =  NONE 

(Although  the  value  constructor  NONE  takes  no  argument,  the  refinement  type  constructor 
none  does  take  one  argument  because  it  refines  the  ML  type  constructor  option  which  takes 
one  argument.) 

Suppose  we  have  a  collection  of  rewrite  rules  which  only  apply  sometimes.  We  can 
represent  one  of  these  rules  as  a  function  with  the  type 

a—* a  option 

If  the  rewrite  rule  rew  applies  to  a  value  x,  then  raw  x  =s>  SOME  y,  where  y  is  the  result  of 
rewriting  x.  If  the  rewrite  rule  does  not  apply,  then  raw  x  =>  NONE. 

One  natural  thing  to  do  with  a  rewrite  rule  to  repeat  it  until  it  no  longer  applies;  the 
result  is  a  rewrite  rule.  We  can  write  this  as  a  straightforward  higher-order  function: 

fun  rapaat  raw  x  = 
case  raw  x  of 
NONE  =>  SOME  x 
I  SOME  y  =>  repeat  raw  y 

which  has  the  ML  type  (a  — »  a  option )  — >  a  — >  a  option. 

Now,  assuming  an  infinite  number  of  refinement  type  variables  refine  each  ML  type 
variable,  what  is  the  type  for  repeat?  Suppose  the  refinement  type  of  the  value  bound 
to  x  is  ai.  Perhaps  the  value  bound  to  x  will  be  rewritten  zero  times;  this  happens  if  the 
argument  to  repeat  has  type  e*i  — ►  02  none ,  so  repeat  has  the  type 

(on  — *  <*2  none)  — »  oj  — >  aj  some 

The  value  bound  to  x  may  also  be  rewritten  once.  This  happens  if  the  rewriter  has  type 

cti  — ►  d2  some  A  02  — » 03  none, 


so  repeat  also  has  the  type 


(ai  — >  02  some  A  02  — ♦  03  none )  — >  ai  — ♦  02  some. 
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We  can  continue  in  this  fashion,  giving  types  for  repeat  that  describe  its  behavior  when 
the  rewrite  rule  applies  any  nonnegative  number  of  times.  The  only  type  that  includes  all  of 
this  information  is  the  infinite  intersection  of  all  of  these  possible  types.  Our  system  only 
has  finite  refinement  types,  so  repeat  does  not  have  a  principal  type  if  we  permit  infinitely 
many  refinements  of  an  ML  type  variable.  The  only  natural  choices  for  the  number  of 
refinements  of  each  ML  type  variable  seem  to  be  one  or  infinitely  many.  Since  we  have 
ruled  out  having  infinitely  many,  we  shall  have  only  one. 


4.1.2  ML  Polymorphism  vs.  Refinement  Typing 

Once  we  decide  that  each  ML  type  variable  has  only  one  refinement  (or  any  other  fixed 
number),  ML  polymorphism  interferes  with  refinement  typing.  For  example,  consider  the 
expression 


let  val  not  =  fn  x  =>  if  x  then  false  else  true 
val  double  =  fn  f  =>  fn  x  =>  f  (f  x) 
in 

double  not  true 
end 

There  are  two  ways  to  derive  an  ML  type  for  this  expression.  Either  we  can  have  a 
polymorphic  double  with  the  type  scheme 

V(a).(a  — ♦  a)  — ♦  a  — *  a 

and  instantiate  a  to  bool  when  double  is  used,  or  we  can  have  a  monomorphic  double 
with  the  type  scheme 

V().(Aoo/  — *  bool)  — >  bool  — >  bool 

which  does  not  need  to  be  instantiated  before  it  is  used. 

These  two  ways  to  derive  an  ML  type  for  the  above  expression  have  different  conse¬ 
quences  for  refinement  typing.  If  double  is  polymorphic,  then  clearly  the  only  refinement 
type  scheme  it  can  have  is 

Va.(a  — *  a)  — *  a  — *  a 

Instantiating  a  to  the  refinements  of  bool  gives  an  intersection  with  four  components: 

( T  bool  *  T  booi )  ►  T  bool  >  T  bool  A 

(  -i-  iool  *  J-ioo/  )  *  -L  kool  *  -i-  kool 

If  double  has  this  refinement  type,  then  what  is  the  refinement  type  of 
double  not  true?  The  first  two  components  do  not  help  us  determine  this  type,  since 
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not  has  neither  of  the  types  tt  — ►  tt  nor  ff  — » ff.  The  last  component  is  irrelevant  because 
true  does  not  have  the  type  JL**,/.  Thus  the  only  usable  component  is  the  third  and  the 
best  type  for  double  not  true  is  T 

If,  on  the  other  hand,  double  is  monomorphic,  then  its  type  is  much  more  informative. 
In  the  definition  of  double 


fn  f  =>  fn  x  =>  f  (f  x) 

we  can  assume  that  f  has  the  type  tt—>fff\ff—>tt  and  that  x  has  the  type  tt.  Then  f  x 
has  the  type  ff,  and  f  (f  x)  has  the  type  ff,  so  the  best  type  for  double  not  true  is  tt. 

Thus,  the  programmer  using  refinement  types  will  have  to  have  in  mind  the  same 
derivation  of  the  ML  type  that  the  compiler  has  in  mind  if  he  wants  to  predict  what 
refinement  types  the  compiler  will  assign  to  a  particular  expression.  This  should  not  be 
too  difficult,  since  the  algorithms  actually  used  in  the  compilers  always  generate  the  most 
general  ML  type  at  every  opportunity.  Thus  in  the  example  above  the  programmer  can 
expect  the  compiler  to  use  the  most  general  type  for  double,  which  results  in  the  less 
informative  refinement  type  for  the  let  statement.  If  the  programmer  wanted  the  let 
statement  to  have  the  more  informative  type,  he  could  use  explicit  ML  type  declarations  to 
reduce  the  polymorphism.  One  way  to  do  this  would  be  to  declare  the  second  argument  of 
double  to  have  type  bool,  as  in: 

let  val  not  *  fn  x  =>  if  i  then  false  else  true 
val  double  =  fn  f  =>  fn  x :  bool  ~>  f  (f  x) 
in 

double  not  true 

end 

In  this  thesis  we  avoid  a  choice  among  the  various  algorithms  that  could  conceivably  be 
used  for  ML  type  inference  by  stipulating  that  our  terms  must  have  enough  embedded  ML 
type  information  to  uniquely  determine  how  the  ML  type  is  derived.  This  requires  us  to 
at  least  explicitly  specify  which  variables  each  let  statement  generalizes  over.  This  isn’t 
quite  sufficient  though;  consider  the  let  statement 

let  id  =  A  (a),  fn  x  =>  x 
in 

id  true 

end 

This  expression  has  type  bool.  We  could  have  derived  this  type  by  giving  id  the  type 
scheme  V(a).a  — » a  and  instantiating  a  to  bool  immediately  before  using  id,  or  we  could 
have  derived  it  by  giving  id  the  unusual  type  scheme  V(a).bool  — *  bool  and  instantiating 
a  to  something  arbitrary  before  using  id.  To  eliminate  this  ambiguity,  we  must  have  an 
explicit  declaration  each  place  a  type  variable  could  be  introduced,  which  means  an  explicit 
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declaration  each  time  a  variable  is  used  and  for  each  abstraction.  Because  SML  eagerly 
evaluates  values  bound  by  both  let  and  fn,  we  can  make  our  language  more  uniform  by 
declaring  an  instantiation  for  every  variable  reference,  including  nonpolymorphic  variables 
such  as  x  in  this  example.  Thus  the  fully  explicit  form  of  the  above  let  statement  is: 

let  id  »  A(a).  fn  x:a  *>  x[] 
in 

id[&oo/]  true 

end 

The  constructor  true  does  not  need  the  square  brackets  because  it  is  not  a  variable 
and  because  constructors  will  not  be  polymorphic  until  Chapter  5.  Constructors  can  be 
distinguished  from  variables  because  they  are  explicitly  mentioned  in  the  grammar  for  the 
language  and  in  the  inference  rules. 


4.2  Formally  Incorporating  Type  Variables 

We  will  write  type  variables  as  a,  (3 ;  the  mathematical  variable  that  can  stand  for  any 
type  variable  is  written  a;  context  should  make  it  clear  whether  we  are  talking  about  one 
particular  type  variable  or  an  arbitrary  type  variable. 

The  new  grammars  for  ML  types  and  refinement  types  have  no  surprises;  we  simply 
add  productions  for  type  variables: 

t  ::=  tc  1 1  *  . . .  *  t  |  tunit  1 1  — *  t  |  a 
r  ::=  rArjr— >r|nc|r*...*r|  runit  |  a 

We  write  a  possibly  empty  vector  of  type  variables  as  a.  We  also  have  vectors  of 
refinement  types  r ,  and  so  forth.  We  can  substitute  a  vector  of  refinement  types  r  for  a 
vector  of  type  variables  a  in  a  refinement  type  r  by  using  the  notation  [r  /a)r.  The  length 
of  the  vector  a  is  written  length(a),  and  the  t’th  element  is  written  a{t}.  The  first  element 
is  a{  1 },  not  a{0}. 

We  define  ML  type  schemes  to  have  the  form  V(a).t,  and  refinement  type  schemeto  have 
the  form  V(a).r. 

The  only  changes  we  must  make  the  object  language  grammar  on  page  19  is  adding  let 
statements  and  adding  instantiations  after  each  variable  reference  as  discussed  on  page  228; 
the  entire  grammar  is: 

e  ::=  *[t|  j  fn  x:t  =>  e  |  e  e  |  c  e  | 

case  e  of  c  =>  e  1  ...  J  c  ->  e  end :t  | 

(e . e)  |  ()  |  elt_m_n  e  | 

fix  fit  =>  fn  x:t  =>  e| 
let  x  -  A(a).e  in  e  end 
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let  double  =  A(a).fn  f:a-*a  *>  fn  x:a  =>  f[]  (f[]  x[]) 
in 

let  not  »  A().  in  arg  :bool  => 
case  arg[]  of 

True  =>  fn  _  =>  False  () 

I  False  **>  fn  _  *>  True  () 
end:  bool 
in 

double [600/]  not[]  (True  ()) 

end 

end 


Figure  4.1:  Sample  Expression  Using  Polymorphism 

We  define  an  expression  scheme  to  have  the  form  A (a).e,  as  appears  in  the  grammar  for 
let  statements.  If  a  variable  is  bound  by  a  let,  then  the  substitution  after  it  specifies  how 
to  instantiate  the  expression  scheme  before  use.  If  the  variable  is  bound  by  a  fn,  then 
the  substitution  must  be  trivial  (that  is,  both  the  vector  of  ML  types  and  the  vector  of  type 
variables  must  have  zero  length).  For  this  chapter,  we  assume  that  our  value  constructors  are 
still  monomorphic.  An  example  of  the  syntax  is  in  Figure  4.1.  The  problem  of  convening 
human  readable  code  into  this  syntax  is  simply  ML  type  inference. 

In  Chapter  2,  we  defined  substitution  of  closed  expressions  for  variables  in  expressions. 
Because  the  expressions  were  closed  and  there  were  no  type  variables  in  the  language  at 
the  time,  the  problem  of  variable  capture  did  not  arise.  In  the  present  case,  we  still  limit 
substitution  to  expressions  with  no  free  object  language  variables,  but  they  may  have  free 
type  variables  that  can  be  bound  by  let  statements;  thus  we  now  have  to  deal  with  the 
possibility  of  type  variable  capture  during  substitution.  For  example,  the  terms 

let  y  *  A(a).x[]  in 

y [bool]  (true  ())  (4.1) 

end 

and 

let  y  =  A(/?).x[]  in 

y [bool]  (true  ())  (4.2) 

end 

have  the  same  meaning  in  some  intuitive  sense.  If  we  ignore  the  issue  of  variable  capture 
while  substituting  A().fn  z:a  =>  z  []  for  x  in  each  of  these,  we  get 

let  y  =  A(a).fn  z:a  ->  z  []  in 
j[bool]  (true  ()) 

end 
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let  y  ■  A(/3).fn  z :a  *>  z  []  in 

y[ bool]  (true  ())  (4.3) 

end. 

Something  has  gone  wrong  here  because  these  expressions  no  longer  have  intuitively 
equivalent  meanings;  in  fact,  in  the  ML  type  system  we  define  below,  the  first  has  well- 
formed  ML  types  but  the  second  does  not.  The  problem  occurred  when  we  substituted  an 
expression  with  a  free  a  into  a  context  in  which  a  was  bound.  There  are  several  ways  we 
could  have  prevented  the  problem. 

First,  we  could  simply  forbid  substitutions  that  cause  variable  capture.  This  would  mean 
that  (4.1)  and  (4.2)  are  no  longer  equivalent,  because  the  substitution  above  is  forbidden 
for  (4.1)  but  permitted  for  (4.2).  This  is  aesthetically  unpleasing,  but  similar  to  approaches 
taken  by  others  in  the  past;  for  example,  with  slightly  different  notations,  the  papers 
[Car87,  CDDK86,  DM82,  Myc84,  Tof88]  all  define  systems  that  allow  one  to  derive 

/  ;  a  f-  fn  x  *>  x  ::  V/3./3  — >  /? 

but  not 

/  :  a  I-  fn  x  =>  x  ::  Va.a  —*  a. 

There  are  other  approaches,  such  as  higher-order  abstract  syntax[PE88,  MNPS91, 
HHP93]  and  de  Bruijnindices  [Bar80,  dB72J,  that  solve  the  problem  by  changing  or  elimi¬ 
nating  the  notion  of  “named  variable”.  These  seem  too  radical  for  the  task  at  hand. 

Instead,  we  will  circumvent  the  problem  by  giving  a  different  meaning  to  (4.1)  and 
(4.2)  so  they  are  actually  the  same  mathematical  object,  as  was  done  in  [Bar80,  page  26] 
and  [CR36].  In  this  approach,  we  identify  two  expressions  if  we  can  transform  one  into 
the  other  by  renaming  bound  variables,  and  whenever  we  write  an  expression,  we  really 
mean  the  equivalence  class  containing  that  expression.  In  this  case  the  proper  definition  of 
substitution  still  forbids  variable  capture  as  a  special  case,  but  we  can  always  find  an  element 
of  the  equivalence  class  that  makes  the  substitution  go  through.  With  this  interpretation,  the 
correct  result  of  the  substitution  mentioned  above  is  (4.3).  We  use  the  same  strategy  to  deal 
with  binding  object  language  variables;  thus  f  n  y :  bool  =>  y[]  and  f  n  x :  bool  =>  x[]  are 
the  same  term,  as  are 

let  x  =  A(a).fn  z  :a  =>  z[]  in  x[ioo/]  end 


and 


let  y  =  A(a).fn  z:a  =>  z[]  in  y[6oo/]  end. 

Now  that  we  have  a  clear  policy  for  dealing  with  type  variable  capture,  we  can  modify 
the  definition  of  substitution  on  page  23  so  we  now  substitute  expression  schemes  (not 
expressions)  for  variables  in  expressions.  Only  a  few  of  the  clauses  of  the  substitution 
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definition  change  in  a  non-trivial  way;  the  first  clause  listed  uses  the  operation  of  substituting 
ML  types  for  type  variables  in  expressions,  which  is  a  simple  operation  we  shall  not  formally 
define  here: 

[A(a).e/®](*(i])  =  [f/a]e  if  length(a)  =  length(t) 

[A(a).e/®](*[f  ])  fails  otherwise 
[A(a).e/®](y[f  j)  =  y[t]  ify  ^  ® 

[A(a).ei/®](l«t  y  *  A(/3).e2  in  e3  end)  = 

(let  y  -  A(/?).[A(a).ei/®]e2  in  [A(a).ei/®]e3  end) 
where  ®  ^  y  and  a  and  (3  have  no  elements  in  common. 

For  example,  substituting  A(a).fn  x:a  =>  x[]  for  y  in  y{bool\  (true  ())  yields 

(fn  x :  bool  =>  x[])  (true  ()), 

and  substituting  A().true  ()  for  x  in  (x[] ,  xQ)  yields  (true  (),  true  ()). 

The  grammar  for  values  is  unchanged,  but  the  meaning  changes  slightly  because  the 
grammar  references  expressions,  and  expressions  have  changed: 

v  ::=  c  v  |  (t>,  ...»  u)  |  ()  |  fn  ®:f  =>  e 

The  changes  to  the  evaluation  relation  defined  in  Figure  2. 1  on  page  24  consist  of  adding  a 
rule  for  let  and  modifying  rules  that  do  substitution  to  construct  trivial  expression  schemes 
so  we  can  use  the  modified  definition  of  substitution  above: 

ex  =>  vi 

[(A(a).i;i)/®]e2  =>  i>2 
let  x  =  A(a).ei  in  e2  end  =>  v2 

e\  =>  f  n  x :  t  =>  e3 

e2  =>•  «2 

[(A().tt2)/®]e3  =»  v3 
e\  e2  u3 


LET-SEM: 


appl-sem: 


FIX'SEM:  f ix  f:t  ->  fn  x:u  =>  e  => 

[(A().fix  f:t  ®>  fn  ®:u  =>  e)//]fn  x:u  =>  e 


Notice  that  the  let-semrule  says  to  eagerly  evaluate  the  variable  in  let  statements.  There 
have  been  proposals  to  evaluate  them  lazily  under  some  circumstances;  we  could  do  that 
with  the  alternative  rule 


LET-SEM’: 


[(A(a).ei)/®]e2  =>  v2 
let  ®  =  A(a).ej  in  e2  end  => 


Since  we  do  not  have  polymorphic  type  constructors  yet,  our  value  constructors  will  not 
have  polymorphic  outputs.  Thus  it  would  be  peculiar  for  them  to  have  polymorphic  inputs; 
for  example,  consider  this  declaration: 
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datatype  foo  =  Bar  of  a 

Standard  ML  disallows  datatype  declarations  where  the  constructors  have  type  variables 
free  in  the  input  type  (a  in  this  example)  that  are  not  free  in  the  output  type  (Joo  in  this 
example),  so  we  shall  forbid  them  also.  Since  we  cannot  have  a  polymorphic  output  type 
in  this  chapter,  we  will  outlaw  type  variables  in  the  input  type  altogether: 

Assumption  4.1  (Free  Type  Variables  in  Constructors)  If 


then  t  has  no  type  variables. 

The  modifications  to  the  ML  type  system  introduce  few  surprises.  The  environment 
VM  now  maps  variable  names  to  ML  type  schemes.  For  uniformity,  it  maps  all  variable 
names  to  ML  type  schemes,  even  the  variables  bound  by  fn  and  fix;  as  the  abs- valid  rule 
below  says,  all  such  variables  are  bound  to  vacuous  ML  type  schemes  that  quantify  over 
zero  tyr  .ariables.  We  add  a  rule  for  let  statements,  and  make  slight  modifications  to  the 
rules  f  v.  ariables,  abstractions,  and  fixed  points  to  accommodate  the  new  environment: 


LET-VALID: 


VM  F  e,  ::  t, 

for  all  a  in  a  we  have  a  is  not  free  in  VM 
VMJ*  :=  V(a).tj]  I-  e2 ::  t 
VM  F  let  x  =  A(a).ej  in  e2  end ::  t 


VAR-VALID: 


ABS-VALID: 


VM(«)  =  V(a).t 
length(a)  =  length(it) 
VMhifi]  »  [</aJf 

VM[s  VQ.fi]  t~  e  ::  t2 
VM  F  (f n  x:t\  =>  e)  ::  t\  — >  f2 


FIX-VALID: 


VMf/  :=  VQ.fi  — » t2]  F  (fn  x :  t\  =>  e)  ::  t\  — > 
VM  F  (fix  ->  fn  x:t\  =>  e)  ::  t\  — »<2 


Fact  2.3  (ML  Type  Soundness)  on  page  27  and  Lemma  2.4  (Unique  Inferred  ML  Types)  on 
page  27  still  hold  for  the  modified  language,  as  do  Fact  2.5  (ML  Free  Variables  Bound)  on 
page  29  and  Fact  2.6  (ML  Value  Substitution)  on  page  29. 

We  augment  the  refinement  rules  in  Figure  2.3  on  page  31  b,  asserting  that  each 
refinement  type  variable  refines  the  corresponding  ML  type  variable: 


var-ref: - 

a  C  a 
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We  say  r  C  t  if  length(r)  =  length(i)  and,  for  i  between  1  and  length(r),  we  have 
r  {»}  c  t  {t}.  A  refinement  type  scheme  refines  an  ML  type  scheme  if  they  quantify  over 
the  same  variables  and,  after  stripping  off  the  quantifiers,  the  underlying  refinement  type 
refines  the  underlying  ML  type. 

Lemma  2.10  (Unique  ML  Types)  on  page  31  is  still  true;  the  added  case  to  the  proof  is 
trivial,  and  we  shall  omit  it.  We  augment  the  definition  of  rtom  on  page  32  so  it  also  works 
on  substitutions  mapping  type  variables  to  refinement  types;  for  example, 

nom([tt/a,ff /f3])(tn  x:a*/3  =>  x[])  = 

[bool/a,  bool/f3](fn  x:a*(3  =>  x[])  - 

fn  x’.bool  *  bool  =>  x[]. 

Fact  2.12  (Tuple  Refines)  on  page  32  is  still  true. 

We  need  to  make  no  change  to  the  subtyping  rules  in  Figure  2.4  on  page  35,  since  the 
SELF-SUB  rule  ensures  that  refinement  type  variables  are  subtypes  of  themselves.  Similarly, 
we  do  not  need  to  change  the  rules  for  splitting  in  Figure  2.5  on  page  48  because  the 
SELF-SPLIT  rule  deals  with  refinement  type  variables. 

Now  that  we  have  both  substitution  and  subtyping,  we  have  to  show  that  they  interact 
with  each  other  in  the  natural  way: 


Fact  4.2  (Type  Substitution  Preserves  Subtyping)  If  r  <  k,  then  for  any  well-formed ' 
substitution  s,  we  have  s(r)  <  s(k). 


The  proof  of  this  is  by  induction  on  the  derivation  ofr<k. 

We  also  need  to  prove  that  substitution  and  splitting  interact  in  a  natural  way: 


Fact  4.3  (Split  Substitution)  Ifr  x  {rj , . . . ,  rn},  then  for  any  r'  and  a  we  have 


[r'la\r  x  {[r'/ajr,,. . . ,  [r'/a]r„}. 


The  proof  of  this  is  a  simple  induction  on  the  derivation  of  the  hypothesis. 

The  changes  to  refinement  type  inference  are  entirely  analogous  to  the  changes  to  ML 
type  inference.  The  variable  environment  VR  now  contains  refinement  schemes  rather  than 
simple  refinement  types.  Starting  with  the  rules  in  Figure  2.6  on  page  60,  we  add  a  rule 
for  let,  change  the  rule  for  variables,  and  make  minor  changes  to  the  rules  for  abstractions 
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and  fixed  points: 


LET-TYPE: 


VR  H  ei  :  r, 

for  all  a  G  a  we  have  a  not  free  in  VR 

_ VR[»  :=  V(a).rj]  h  e2  :  r _ 

VR  f-  let  x  *  A(a).ei  in  e2  end :  r 


VR(*)  =  V(a).r 
r  C  t 

VAR-TYPE:  _  . 

_ rCt _ 

VR  I-  x[<] :  [r /a]r 


abs-type: 


VR[g  :=  VQ.r]  t-  e  :  k  rdf 
VR  h  In  x:t  =>  e  :  r  — >  k 


rCtx-^h 

FIX-TYPE:  VR[/  :=  VQ.r]  F  (fn  x:tx  =>  e) ;  r 

VR  I- (f  ix  f:t\—*t2  “>  fn  x:t\  =>  e)  :  r 

In  the  syntax  example  in  Figure  4. 1  on  page  229,  using  the  LET-TYPE  rule  on  the  outer  let 
statement  leads  us  to  add  the  type  scheme 

V(a).(a  — » a)  — *  a  — ►  a 

for  double  to  the  type  environment  before  inferring  a  type  for  the  inner  let  statement. 
Then  we  add  the  trivial  type  scheme 

V().f<  — *  tt  A  ff  — ►  ffA  .1*0,1  — >  -Ljoof  AT *ooi  — >  T *„/ 

for  not.  The  only  way  we  can  instantiate  double  that  allows  the  application 

(double[6oo/]  not[])  (True  ()) 

to  have  a  type  is  to  substitute  T  *,,1  for  a;  if  we  do  this, 

double[fool] 


gets  the  type  (T**,/  — » T *,«<)  -*  T*,,,  — ►  T*,,,, 


double  [fool]  not[] 


gets  the  type  T*„i  — ♦  T  iocl,  and 

(double[6ool]  not[])  (True  ()) 
and  the  let  statement  as  a  whole  has  the  type  T 
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Compatibility  with  ML  is  unaffected  by  the  new  rules  added.  We  will  omit  the  simple 
case  for  let  that  must  be  added  to  the  proof  of  Theorem  2.54  (Inferred  Types  Refine)  on 
page  68,  and  the  proofs  of  Lemma  2.55  (Value  Arrow  Type)  on  page  74  and  Fact  2.56 
(Value  Constructor  Type)  on  page  74  are  unchanged.  We  must  add  this  equation  to  the 
definition  of  mtor  on  page  76: 

mtor(a)  =  a; 

the  proofs  of  Fact  2.61  (mtor  Refines)  on  page  76  and  Fact  2.62  (Unique  Refinement)  on 
page  76  are  still  trivial,  and  the  case  we  must  add  to  deal  with  let  statements  in  Theorem 
2.64  (ML  Compatibility)  on  page  77  is  simple  and  we  will  omit  it. 

Updating  the  soundness  proof  is  somewhat  more  work,  and  constitutes  most  of  the 
remainder  of  this  chapter.  The  statement  of  Lemma  2.66  (Environment  Modification)  on 
page  81  does  not  change;  the  var-type  case  of  the  proof  changes  slightly:  The  statement 
of  Lemma  2.66  (Environment  Modification)  on  page  81  does  not  change;  the  proof  only 
changes  slightly: 

Lemma  4.4  (Environment  Modification)  If 

VR  h  e  :  r 


and 

and 

then 


VR'  has  the  same  domain  as  VR 
for  x  free  in  e  we  have  VR'(z)  <  VR(i) 
VR'He:  r. 


Also,  if  in  addition 
and 

then 


VRH-e  :  r 

e  is  not  a  variable 
VR'H-e:  r. 


Proof:  By  induction  on  the  derivation  of  VR  h  e  :  r. 

Then  e  has  the  form  z[t],  and  r  has  the  form  [r /ajfe  where  the  premises 


Case:  VAR-TYPE 


of  var-type  are: 


VR(*)  =  V(a).Jfe 
f  nt 
k  C  t. 


(4.4) 
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Since  VR(x)  <  VR'(x),  we  know  that 

VR'(x)  «  V(a).*' 


(4.5) 


for  some  k'  <  k.  By  the  version  of  Theorem  2.21  (Subtypes  Refine)  on  page  36  that  holds 
for  this  system,  k'  C  t.  Then  we  can  use  var-TYPE  with  the  premises  (4.5),  (4.4),  and 
k'  C  t  to  get 

VR' H  x(i]  :  [r/5]Jfe'. 

Then  Fact 4.2  (Type  Substitution  Preserves  Subtyping)  on  page  233  gives  [r /a] k'  <  [r  /a] k, 
and  WEAKEN-TYPE  then  gives  VR'  F  x[<] :  [f  /a]k,  which  is  our  conclusion. 


Case:  Otherwise. 


Omitted. 


□ 


Lemma  2.67  (Piecewise  Intersection)  on  page  84  and  Lemma  2.68  (Subtype  Iirelevancy) 
on  page  88  are  unchanged  because  values  do  not  have  let  statements  at  the  top  level. 
Theorem  2.69  (Splitting  Value  Types)  on  page  89  is  changed  slightly  because  it  has  to  use 
Fact  4.3  (Split  Substitution)  on  page  233. 

Lemma  2.70  (Value  Substitution)  on  page  93  becomes  slightly  more  interesting.  We 
have  to  add  a  case  for  let  declarations  and  make  nontrivial  changes  to  the  case  for  variables. 
The  new  type  inference  rule  for  variables  specifies  a  refinement  type  substitution,  so  we  need 
to  be  able  to  substitute  refinement  types  for  type  variables  in  refinement  type  derivations: 


Fact  4.5  (Refinement  Type  Substitution)  Suppose  VR  h  e  :  r  and  s  is  a  substitution 
mapping  type  variables  to  refinement  types  where  for  all  a  in  the  domain  ofs  we  have  a(a) 
is  well  formed.  Then 

s(VR)  h  rtom(a)(e)  :  a(r). 


The  proof  of  this  is  a  simple  induction  on  the  derivation  of  VR  he:r.  The  split-type 
case  uses  Fact  4.3  (Split  Substitution)  on  page  233. 

This  fact  is  useful  in  variable  case  of  Value  Substitution;  we  shall  restate  that  lemma 
and  give  the  let  and  variable  cases  of  the  proof  : 

Lemma  4.6  (Value  Substitution)  If 


VR  1-  ex  :rx, 

where  ex  is  a  value  or  a  closed  expression  of  the  form  fix  f:tx  =>  fn  x:t2  ~>  e",and 

VR[x  :=  v(a).rj]  h  e2  :  '-2, 

and  none  of  the  variables  in  a  are  free  in  VR,  and  the  substitution  [( A(a).ej  )/x]e2  succeeds, 
then 


VR  h  [(A(a).et)/x]e2  :  r2. 
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Proof:  By  induction  on  the  derivation  of  VR[x  :=  V(a).ri]  F  e2  :  r2. 

Case:  VAR-TYPE  Then  e2  has  the  form  y[. . .]  for  some  y.  If  y  is  not  x,  then  the  desired 

conclusion  is  VR  F  e2  :  r2.  We  can  get  this  by  eliminating  the  unused  variable  x  from  the 
hypothesis  VR[x  :=  V(a).n]  F  e2  :  r2. 

Otherwise,  e2  has  the  form  x[t].  By  the  shape  of  var-TYPE,  r2  has  the  form  [r/a]ri. 
The  premises  of  var-TYPE  must  be  r  C  t  and,  for  some  t,  ri  C  t.  By  Fact  4.5  (Refinement 
TVpe  Substitution)  on  page  236, 

[r/a](VR)  t-  rtom([r/a])(ei) :  [r/a](ri).  (4.6) 

By  hypothesis,  none  of  the  variables  in  a  are  free  in  VR,  so  [r  /a](VR)  =  VR.  By  definition 
of  substitution,  [(A(a).ei)/xje2  =  [(A(a).et)/x](x[F])  =  [i/ajej  =  rtom([r /a])(ei). 
Since  r2  =  [r  /a\r{,  (4.6)  is  our  conclusion. 

Case:  LET-TYPE  Then  e2  has  the  form  let  y  =  A(/9).e3  in  e4  end  for  some  y.  Rename 

variables  if  necessary  to  ensure  that  y  and  x  are  distinct,  and  that  a  and  /?  have  no  variables 
in  common.  For  some  r3,  the  premises  of  let-type  must  be 

VR(x  :=  V(a).ri]  I-  e3  :  r3, 

for  all  /3  (z  0  we  have  (3  not  free  in  VR[x  :=  V(a).r!], 

and  _ 

VR[x  :=  V(a).ri,y  :=  V(/3).r3]  h  e4  :  r2. 

Let  L  abbreviate  A(a).et;  then  our  induction  hypothesis  gives 

VR  F  {L/x]e3  :  r3 
and 

VR[y  :=  V(/?).r3]  h  [L/x\e4  :  r2. 

Then  LET-TYPE  gives 

VR  h  let  y  =  A(/3).[L/x]e3  in  [i/xje4  :  r2; 
by  definition  of  substitution,  this  is  our  conclusion. 

Case:  Otherwise  Omitted.  □ 

We  are  finally  able  to  give  the  modifications  of  Theorem  2.71  (Refinement  Type  Sound¬ 
ness)  on  page  99  necessary  for  the  system  described  in  this  chapter.  Although  the  statement 
of  the  theorem  does  not  change,  we  will  repeat  it  here: 

Theorem  4.7  (Refinement  Type  Soundness)  Ife=*v  and  •  h  e  :  r,  then  •  F  v  :  r. 
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Since  e  is  closed,  it  is  not  a  variable;  thus  the  only  change  we  need  to  make  to  the  previous 
version  of  the  proof  is  to  deal  with  the  possibility  that  e  may  be  a  let  statement. 

Proof:  By  cases  on  the  pair  (root  inference  of  e  =>  v,  root  inference  of  •  I-  e  :  r). 

Case;  (LET-SEM, LET-TYPE)  Then  e  must  have  the  form  let  x  *  A(a).ei  in  e2  end. 
The  premises  of  LET-SEM  must  be 

ei  =►  i>i  (4.7) 

and 

[(A(a)-wi)/*]c2  v.  (4.8) 

For  some  r,  the  premises  of  LET-TYPE  must  include 

•  (-  ei  :  ri  (4.9) 

and 

VR[s  :=  V(a).ri]  h  e2  :  r.  (4-10) 

Using  the  induction  hypothesis  on  (4.7)  and  (4.9)  gives 

•  b  vj  :  t\ 

Value  Substitution  and  (4.10)  then  give 

•  1-  [(A(a).vi)/»]e2  :  t. 

Using  the  induction  hypothesis  on  this  and  (4.8)  gives  -  I -  v  :r,  which  is  our  conclusion. 

Case:  Otherwise  Omitted.  D 

The  proofs  of  Theorem  2.90  (Finite  Refinements)  on  page  115  and  Corollary  2.91 
(Principal  Refinement  Types)  on  page  1 15  are  essentially  unchanged. 

The  only  significant  change  to  the  decision  procedure  is  modifying  the  infer  function 
defined  in  Figures  2.7  and  2.8  on  pages  142  and  143  to  deal  with  let  statements  and  the 
new  syntax  for  variable  references.  The  new  cases  are: 


4.2.  FORMALLY  INCORPORATING  TYPE  VARIABLES 
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fun  infer  VR  y[?]  ■ 

if  VR(y)  is  undefined  or 

VR(y)  does  not  have  the  form  V(a).r 
where  r  refines  some  t 

then  ns 
else 

let  val  V(a).r  »  VR(y) 
in 

Afn  {[r/a]r  |  length(r)  =  length(a)  and 

for  all  *  we  have  f  {*}  Gallref  s(i{t})} 

end 

I  infer  VR  (e  as  (let  *  =  A(a).ej  in  ti  end))  = 
let  val  k  =  infer  VR  e\ 
val  a  =  split  ( k ) 

val  u  *  the  unique  u  such  that  rtom(VR)  H  e  ::  u 
in 

sjoinf  u  {infer  (VR[x  :=  V(a).p])  |  p  G  s} 

end 

The  correctness  proof  for  the  revised  case  for  variables  has  no  surprises,  and  the  proof  for 
the  let  case  uses  no  concepts  that  do  not  appear  in  the  application  or  abstraction  cases,  so 
we  shall  omit  them. 

By  Assumption  4.1  (Free  Type  Variables  in  Constructors)  on  page  232,  there  cannot 
be  any  type  variables  in  rectype  declarations.  Thus  the  argument  in  Chapter  3  needs  no. 
revisions  to  accommodate  the  type  variables  introduced  in  this  chapter. 

To  summarize,  once  we  decide  that  each  ML  type  variable  is  refined  by  exactly  one 
refinement  type  variable,  the  formal  description  of  refinement  types  with  type  variables 
follows  straightforwardly. 


Chapter  5 

Polymorphic  Refinement  Type 
Constructors 


Programmers  intuitively  know  that  all  even  length  lists  of  true’s  are  also  even  length 
lists  of  booleans.  With  polymorphic  refinement  type  constructors,  we  can  write  this  as 
tt  ev  <  T m  ev,  where  ev  is  the  type  of  lists  with  even  length.  This  chapter  is  about 
formalizing  that  intuition  in  the  type  system. 

We  say  that  the  type  argument  to  ev  is  a  positive  type  argument,  since  as  the  type 
argument  of  ev  gets  larger,  the  type  as  a  whole  gets  larger.  There  are  other  possibilities;  for 
example,  suppose  we  have  the  declaration 

datatype  a  pred  =  Pred  of  a  — *  bool 
rectype  a  tpred  =  Pred  (a  — *  tt) 
and  at  fpred  -  Pred  (a  — » ff) 

Using  an  intuitive  reading  of  this  rectype  declaration,  we  would  expect  to  be  able  to  apply 
Pred  to  a  function  with  type  tt  — >  tt  and  get  a  value  of  type  tt  tpred;  similarly,  we  would 
expect  to  be  able  to  apply  Pred  to  a  function  with  type  — >  tt  and  get  a  value  of  type 

T iooi  tpred.  Since  T i(K,/  — ►  tt  <  tt  — >  tt,  we  expect  T ^  tpred  <  tt  tpred.  We  say  the 
type  arguments  of  pred,  tpred,  and  fpred  are  all  negative. 

There  are  two  other  possibilities.  We  can  have  a  type  variable  that  appears  on  both  the 
left  and  the  right  side  of  an  arrow,  such  as 

datatype  am  =  Mofa— >a, 

where  tt  Tm  is  incomparable  with  Tw  Tm.  We  say  the  type  argument  of  m  is  mixed. 

We  can  also  have  type  variables  that  appear  nowhere  in  the  type,  such  as 

datatype  a  i  *  B  of  bool 
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where  tt  T  j  =  T,-.  We  say  the  type  argument  of  i  is  ignored.  It  turns  out  that  positive, 

negative,  mixed,  and  ignored  are  all  the  possibilities. 

Since  our  type  system  is  an  approximation  instead  of  an  all-knowing  oracle,  we  have  the 
option  of  ignoring  any  or  all  of  the  above  distinctions,  so  long  as  the  resulting  approximation 
is  conservative.  We  could  take  the  least  informative  approximation  in  all  cases;  this  would 
mean  treating  all  type  arguments  as  mixed  type  arguments.  In  this  case  the  refinement  types 
tt  ev  and  T 4*,/  ev  would  be  incomparable.  With  this  interpretation,  tt  ev  would  no  longer 
be  a  principal  type  of  cons  (true,  cons  (true,  nil)),  since  the  type  tt  ev  A  T *«,/  ev 
would  be  another  type  for  that  expression  that  is  strictly  smaller.  This  approach  has  not  been 
explored  enough  to  determine  how  many  unpleasant  surprises  it  gives  the  programmer,  but 
nevertheless  we  will  not  go  that  way. 

Another  approach  is  to  simplify  things  by  outlawing  some  of  the  possibilities;  since  all 
of  the  possibilities  are  permitted  in  Standard  ML,  this  implies  becoming  less  compatible 
with  Standard  ML.  The  current  implementation  does  this;  it  outlaws  mixed  type  arguments 
and  it  treats  ignored  type  arguments  as  though  they  were  positive.  However,  in  this  chapter 
we  will  permit  and  accurately  model  all  four  possibilities. 

Thus,  in  general,  each  polymorphic  refinement  type  constructor  will  have  four  kinds  of 
type  arguments.  We  will  represent  the  different  kinds  by  grouping  them  together,  separated 
by  semicolons,  in  the  order  negative,  positive,  mixed,  and  ignored.  For  example,  the  true 
form  of  tt  ev  is  (;  tt; ; )  ev. 

Each  ML  type  constructor  takes  a  fixed  number  of  type  arguments;  each  of  these  is  either 
negative,  positive,  mixed,  or  ignored.  We  will  assume  these  type  arguments  are  grouped 
as  described  in  the  previous  paragraph,  so  we  can  describe  the  number  of  arguments  an 
ML  type  constructor  takes  with  a  tuple  of  four  nonnegative  integers  saying  how  many 
arguments  it  takes  of  each  type.  We  call  this  tuple  the  arity  of  the  ML  type  constructor, 
and  if  we  call  the  ML  type  constructor  tc  then  we  write  its  arity  as  arity(ic).  For  instance, 
arity(fcst)  =  (0;  1;0;0)  and  arity(m)  =  (0;0;  1;0).  Assumption  2.2  (Constructors  have 
Unique  ML  Types)  on  page  26  still  holds,  so  we  can  assume  that  the  arity  function  is  defined 
for  ML  type  constructors,  and  define  arity  (re)  to  be  arity  (tc)  for  the  unique  tc  such  that 

def 

rc  C  tc. 

With  these  conventions,  we  can  define  arrow  and  tuple  types  as  uses  of  ordinary  type 
constructors.  With  this  interpretation,  many  of  the  inference  rules  concerning  tuple  or  arrow 
types  are  subsumed  by  more  general  rules.  Specifically,  we  shall  treat  the  ♦”  operator 
that  appears  in  ML  types  as  an  ordinary  ML  type  constructor  with  arity  (1;  1;  0;  0);  we  shall 
call  it  tar-row  when  we  are  thinking  of  it  in  this  context.  We  also  have  an  *”  operator  in 

def 

refinement  types;  we  will  call  it  rarrow,  and  we  have  the  assumption  rarrow  c  tar-row. 
We  will  continue  to  use  but  now  it  is  a  readable  abbreviation  for  a  use  of  rarrow 
or  tarrow ,  rather  than  part  of  the  syntax.  For  example  bool  — *  bool  is  syntactic  sugar  for 
(bool;  bool; ; )  tarrow  and  tt  — >  ff  is  syntactic  sugar  for  (tt;  ff; ; )  rarrow. 

Similarly,  we  can  represent  tupling  of  ML  types  as  an  ordinary  ML  type  constructor. 
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For  example,  we  give  the  ML  type  constructor  that  takes  arguments  a,  /?,  and  7  and 
constructs  a  *  0  *  7  the  name  ttuple^  which  has  arity  (0;  3;  0;0).  In  general  we  have  an 
ML  type  constructor  ttuplen  for  tuples  of  each  nonnegative  size  n,  and  arity (ttuplen)  = 
(0;  n;  0;  0).  Refinement  type  tuples  get  their  own  constructor,  named  rtuplen,  and  for  all 

(Jcf 

nonnegative  n  we  have  rtuplen  C  ttuplen.  We  will  continue  to  use  the  old  syntax  as 
syntactic  sugar  for  the  new;  for  example,  runit  stands  for  (; ; ; )  rtuple0  and  bool  *  bool 
stands  for  (;  bool,  bool; ; )  ttuple2. 

We  will  make  the  examples  more  readable  by  using  some  other  syntactic  sugar  too. 
When  a  refinement  or  ML  type  constructor  has  no  arguments,  we  eliminate  the  argument 
list  entirely;  thus  we  write  bool  instead  of  (; ; ; )  bool.  Also,  if  all  of  the  arguments  are 
positive,  we  omit  the  semicolons,  and  if  there  is  only  one  argument  and  that  argument  is 
positive,  we  omit  the  parentheses;  thus  we  write  bool  list  instead  of  (;  bool; ; )  list. 

To  make  the  rest  of  this  chapter  more  concise,  we  will  introduce  special  notation  for 
groups  of  four  vectors  of  types  or  type  variables.  We  abbreviate  (r  f,  r2;  r3;  r4)  as  r.  We 

define  f  as  a  similar  grouping  of  four  t ’s. 

With  this  said,  it  should  not  be  surprising  that  after  we  expand  all  the  syntactic  sugar, 
the  grammars  for  ML  and  refinement  types  have  become  simpler: 

t  ::  =  (i)tc  j  a 
r  ::  =  r  A  r  |  (r  )nc  )  a 


We  change  the  grammar  for  expressions  by  stating  explicitly  how  to  instantiate  each 
value  constructor  before  using  it.  We  do  this  for  the  same  reason  we  had  an  explicit 
instantiation  after  each  variable  in  Chapter  4:  we  need  the  object  language  to  uniquely 
determine  the  ML  type  derivation.  We  specify  the  ML  types  of  value  constructors  with 
assumptions  of  the  form 

c  t  ( a)tc , 

so  the  easiest  way  to  specify  the  substitution  is  by  giving  a  quadruple  of  types  to  substitute 
for  the  type  variables  a.  Thus  the  new  grammar  for  expressions  is: 

e  ::=  x[t ]  |  fn  x:t  ->  e  j  e  e  |  c[f]  e  | 

case  e  of  c  =>  e  I  ...  I  c  ~>  e  end: t  j 
(e,  ...»  e)  |  ()  |  elt _m_n  e  | 
fix  f:t  =>  fn  x:t  =>  e\ 
let  x  =  A(a).e  in  e  end 

As  we  did  with  type  constructors,  we  may  omit  the  substitution  after  a  value  constructor  if 
it  is  empty;  thus  we  will  write  true  ()  instead  of  true[; ; ;  ]  (). 

Intersections  of  vectors  of  refinement  types  happen  pointwise;  that  is,  if  f  and  k  have 
the  same  length,  then  f  A  k  has  that  length  too,  and  ( r  A  £){*}  =  r{t}  A  fc{i}  for  i 
between  1  and  length(r). 


5.1.  ML  TYPING 
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The  arguments  in  this  chapter  are  a  modification  to  the  arguments  in  Chapters  2  and  4. 
We  will  disregard  trivial  changes  made  to  accommodate  the  change  in  syntax  of  the  object 
language. 

The  definition  of  substitution  on  page  231  does  not  change,  nor  do  the  semantics  rules 
on  page  231. 


5.1  ML  typing 

Now  that  we  have  polymorphic  type  constructors,  we  can  have  polymorphic  datatype 
declarations.  To  permit  this,  we  need  to  revise  Assumption  4.1  (Free  Type  Variables  in 
Constructors)  on  page  232: 

Assumption  5.1  (Free  Type  Variables  in  Constructors)  If 

c  ::  t— *(a)tc 

then  all  type  variables  free  in  t  appear  in  5. 


The  only  change  to  the  appearance  of  the  ML  typing  relation  specified  in  Figure  2.2  on 
page  27  and  updated  on  page  232  are  to  the  rules  for  constructors  and  case  statements: 


CONSTR-VALID: 


c  d\:  t  ■— >  (a)fc  VMhe::  [t/q]t 
VM  h  c[£]  e  ::  ( t)tc 


VM  h  e0  ::  ( t)tc 

case-valid:  for  311  i  we  have  «  "  ti  ^  (a)te 

for  all  i  we  have  VM  h  e i ::  [i/a}ti  — »  u 
VM  I- (case  eo  of  ct  =>  ei  I  ...  I  Cn  =>  en  end:u)  ::  u 

The  meaning  of  these  rules  have  changed,  though,  because  now  -♦  and  *  are  syntactic  sugar 
for  uses  of  polymorphic  ML  type  constructors  instead  of  primitive  symbols.  The  modified 
system  has  all  the  usual  properties;  Fact  2.3  (ML  Type  Soundness)  on  page  27,  Lemma  2.4 
(Unique  Inferred  ML  Types)  on  page  27,  Fact  2.5  (ML  Free  Variables  Bound)  on  page  29, 
and  Fact  2.6  (ML  Value  Substitution)  on  page  29  still  hold. 


5.2  Subtyping 

Because  arrows  and  tuples  are  no  longer  primitive,  we  can  eliminate  some  of  rules  for 
the  refines  relation  “d”  defined  in  Figure  2.3  on  page  31  and  updated  on  page  233.  The 
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VAR -REF: 


a  C  a 


AND- REF: 


RCON-REF: 


rt  C  t  r2Ot 
rt  A  r2  C  t 


rc  C.  tc  ¥  Cj 
[Fjrc  C  [f]fc 


QUADRUPLE-REF: 


fiEti  tz  t2  7*3  C  <3  r4  C  t4 
(?i;  ^2;  ^3;  ^4)  C  (4 1;  ti\  ty  t4) 


length(r)  =  length(J) 

VECTOR-REF:  for  all  i  in  1 . . .  length(r )  we  have  ¥  {»}  C  t{i} 

f  C  t 


Figure  5.1:  Polymorphic  Refinement  Rules 

complete  set  of  rules  is  in  Figure  5.1.  In  these  rules  we  use  the  abbreviation  ¥  (Z  t  to  mean 
that  the  quadruples  ¥  and  t  have  the  same  shape  and,  for  each  r  in  ¥  and  the  corresponding 
t  in  I,  we  have  r  C  t.  We  are  able  to  get  the  effect  of  the  old  ARROW-REF  rule  because  we 
have  the  rcon-ref  and  we  assume 

def 

rarrovj  C  t arrow. 

Similarly,  we  get  the  effect  of  TUPLE-REF  by  using  RCON-REF  and  the  assumption 

def 

rtvplen  C  ttuplen 

for  all  nonnegative  n. 

Lemma  2.10  (Unique  ML  Types)  on  page  31  is  still  true,  and  we  shall  omit  the  proof. 
The  definition  of  rtom  on  page  32  is  unchanged,  as  is  the  addition  that  defines  its  effect  on 
substitutions  on  page  233. 

For  the  same  reason,  we  can  simplify  the  subtyping  rules  that  originally  appeared  in 
Figure  2.4  on  page  35.  First  we  generalize  RCON-SUB  and  RCON-  AND- ELIM-SUB  to  deal  with 
polymorphism,  then  we  eliminate  arrow-sub,  arrow-and-elim-sub,  tuple-sub,  and 
TUPLE-  and- elim-s U B  because  those  rules  are  now  subsumed  by  the  generalized  rcon-sub 
and  RCON-AND-ELIM-SUB.  The  entire  set  of  rules  is  in  Figure  5.2. 

To  use  rcon-sub  with  arrows  and  tuples,  we  need  arrow  and  tuple  refinement  type 
constructors  to  be  subtypes  of  themselves;  thus  we  need  to  have 

def 

rarrow  <  rarrow 


5.2.  SUBTYPING 
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SELF-SUB: 


AND-ELIM-R-SUB: 


AND-ELIM-L-SUB: 


AND-INTRO-SUB: 


trans-sub: 


rcon-sub: 


rcon-and-elim-sub: 


k\ 

quadruple-sub:  — 


VECTOR-SUB: 


VECTOR-EQUIV: 


r  C  t 
r  <t 

r  Q  t  k  C  t 

r  A  k  <  r 

r\Zt  kCt 

r  A  k  <  k 

r  <  fei  r  <  I02 

r  <  k\  A  hi 

r  <p  p<  k 

r  <  k 


=  def 

r  <  k  rc  <  kc 
r  rc  <  k  kc 

_ {t\\t2  A  f'2\  r3;  r4)  C  i _ 

{r  1;  r2;  r3;  r4)  rcA(r,;  r'2;  r3;  r4)  rc'  < 

(r  s;  r2  A  f'2 ;  r3;  r4)  (ty:  A  rc') 

<r\  f2  <  k2  r3  =  k3  r4  C  f  fc4  (Z  t 
(t  1;  r2;  r3;  r4)  <  (fei;  k2;  k3;  k4) 


length(r)  =  length(A:) 
for  i  in  1 . . .  length(r )  we  have  r  {* }  <  *{»■} 
r  <  k 

f  <  k  k  <  r 
f  =  k 


Figure  5.2:  Polymorphic  Subtyping  Rules 
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and,  for  all  nonnegative  n, 


def 

t tuple  n  <  ttuplen. 


Theorem  2.2 1  (Subtypes  Refine)  on  page  36  still  holds.  Lemma  2.22  (Tuple  Intersection) 
on  page  40,  Fact  2.23  (Tuplesimp  Sound)  on  page  41,  Lemma  2.24  (Refinement  Constructor 
Intersection)  on  page  41,  and  Fact  2.25  (Rconsimp  Sound)  on  page  42  will  be  immediate 
corollaries  of  theorems  we  will  prove  below  as  part  of  the  proof  that  each  refinement  type 
still  has  finitely  many  refinements.  Since  we  only  need  these  theorems  for  the  type  inference 
algorithm,  we  will  postpone  discussion  of  them  until  Section  5.5. 

Fact  4.2  (Type  Substitution  Preserves  Subtyping)  on  page  233  still  holds,  as  does  Fact 
4.3  (Split  Substitution)  on  page  233. 


5.3  Finiteness  of  Refinements 


Because  we  have  made  polymorphism  more  general,  the  lemmas  used  to  prove  that  each 
ML  type  has  only  finitely  many  refinements  become  much  more  useful.  Thus  we  shall 
describe  the  appropriate  generalization  of  that  proof  now,  before  we  use  the  lemmas  in  the 
soundness  and  decidability  proofs. 

In  Section  2.9  on  page  105,  we  created  two  interpretations  of  each  refinement  type. 
Two  refinement  types  r  and  k  were  equivalent  if  and  only  if  their  interprets  ,ons  I(r)  and 
I(k)  were  equal,  which  was  true  if  and  only  if  their  interpretations  i(r)  and  i(k)  mapped 
equivalent  refinement  types  to  equivalent  generalized  refinement  types.  This  section 
preserves  this  property  while  generalizing  I  and  » to  apply  to  arbitrary  refinement  types 
with  polymorphic  type  constructors.  The  definition  of  I  in  terms  of  i  is  straightforward,  so 
we  will  discuss  generalizing  i. 

The  proper  generalization  of  i  is  fairly  clear  once  we  determine  what  its  inputs  and 
outputs  should  be.  Since  in  this  chapter  we  have  converted  the  *”  refinement  type 
operator  from  Chapter  2  into  an  ordinary  refinement  type  constructor  with  one  negative 
and  one  positive  argument,  reasoning  by  analogy  with  the  definition  of  t  from  Chapter  2 
leads  one  to  expect  that  the  new  i  will  take  negative  type  arguments  for  input  and  produce 
positive  type  arguments  in  its  output. 

It  is  possible  to  declare  refinement  types  that  behave  similarly  to  rarvow,  except  the 
output  of  the  function  is  represented  as  a  refinement  type  constructor  instead  of  as  a  positive 
type  argument.  For  example,  we  can  reuse  the  pred  datatype: 

datatype  ( a ; ; ; )  pred  =  Pred  of  a—>  bool 
rectype  (a; ; ; )  tpred  =  Pred  (a  — ►  tt) 
and  (a;;;)  fpred  =  Pred  ( a—>ff ) 


5.3.  FINITENESS  OF  REFINEMENTS 


247 


In  this  case,  it  is  obvious,  for  example,  that  a  function  /  has  the  refinement  type  tt—>tt  A 
ff  -»g(f  ifandonlyifPred  /has  the  refinement  type  [tt;;; )  tpredA(ff;;;)fpred.  Thus  we 
expect  refinement  type  constructors  to  have  an  analogous  role  to  positive  type  arguments: 
they  are  outputs  from  the  interpretation. 

The  problem  of  determining  the  role  of  mixed  type  arguments  remains.  We  will  use  this 
example: 


datatype  (; ;  a; )  mix  =  Mix  of  a  — >(a  *  bool ) 
rectype  (; ;  at; )  tmix  =  Mix  (a— >(a  *  ft)) 
and  (;;<*;)  fmix  =  Mix  ( a->(a*ff )) 
and  (;;a;)  botmix  =  Mix  (a  -+(a* 

In  this  case,  the  following  types  are  all  distinct: 

(; ;  tt; )  tmix  A  (; ;  T iool; )  botmix 
(; ;  tt; )  tmix  A  (; ;  T ioel; )  tmix 
(; ;  tt;  )  botmix  A  (; ;  T 4 ool;  )  botmix 
(; ;  tt; )  botmix  A  (; ;  T iool; )  tmix 

It  seems  most  natural  to  give  different  interpretations  to  these  distinct  types  by  making 
mixed  type  arguments  an  input  to  the  interpretation.  From  this  example,  it  is  clear  that 
mixed  arguments  give  rise  to  more  distinct  refinements  than  do  negative  arguments.  We 
must  therefore  have  more  distinct  interpretations  of  refinement  types  with  mixed  arguments; 
this  happens  because  the  interpretation  in  general  is  monotone  for  the  negative  arguments 
but  not  for  the  mixed  arguments. 

In  Chapter  2  we  had  “generalized  refinement  types”,  which  were  either  a  refinement  type 
or  ns.  In  the  argument  below,  we  use  generalized  pairs  for  a  similar  purpose.  A  generalized 
pair  is  either  a  pair  consisting  of  a  vector  of  refinement  types  corresponding  to  the  positive 
arguments  of  some  refinement  type  constructor  and  a  refinement  type  constructor,  or  it  is 
ns.  We  will  use  the  metavariables  tt?,  kkl,  and  pp?  to  stand  for  generalized  pairs.  The 
operations  on  generalized  refinement  types  can  also  be  defined  on  generalized  pairs;  for 
example,  che  new  definition  of  ■<  is  entirely  analogous  to  the  definition  on  page  106: 

Definition  5.2  We  define  the  binary  relation  -<  on  generalized  pairs  by  the  following  cases: 

( r;rc )  ^  ( k;kc)ifandonlyiff  <  k  andrc  <  kc 
(r;  rc)  r<  ns  always 
ns  -<  ( k;kc )  never 
ns  ■<  ns. 

The  definition  of  «  is  also  analogous: 

Definition  53  We  say  rrl  ~  kkl  ifrrl  ■<  kkP.  and  kkP.  ■<  rrl. 
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Definition  5.4  We  define  the  binary  operation  A  mapping  pairs  of  generalized  pairs  to 
generalized  pairs  by  the  equations: 


(F;rc)  A  ( k\kc )  =  (r  A  k\rc  A  kc) 
(F;  rc)  A  ns  =  ns  A  (F;  rc)  =  (F;  rc) 
ns  A  ns  =  ns. 


Definition  5J  Suppose  a  is  a  finite  set  of  generalized  pairs;  then  we  define  A  a  as  follows: 
If  s  is  empty,  then  A s  =  ns. 

If  3  —  {rrl  i , . . . ,  rr?„},  then  A  a  =  rr?i  A  ...  A  rr?n. 


Definition  5.6  We  say  rr?  C  (£;  rc)  i/rr?  =  ns  or  rrl  oc  (r;rc)  and  r  C  t  and  rc  C  rc. 

Definition  5.7  If  a  is  a  finite  set  of  generalized  pairs,  then  we  define  a  C  (t;tc)  to  mean 
that  for  all  elements  rrl  of  a,  we  have  rrl  C  ( t\tc ). 

Fact  2.76  (A  Elim  Sub)  on  page  107,  Fact  2.77  (A  Intro  Sub)  on  page  107,  and  Fact 
2.78  (Transitivity  of  X)  on  page  108  transplant  easily  to  this  new  context,  and  they  continue 
to  hold. 

As  discussed  earlier,  the  new  interpretation  of  a  refinement  type  takes  as  input  two 
sequences  of  refinement  types  corresponding  to  the  negative  and  mixed  arguments  and 
it  outputs  a  generalized  pair.  Interpretations  have  a  simple  property  that  can  almost  be 
used  as  a  definition:  the  interpretation  i  of  a  type  r  is  a  function  /  such  that  for  all 
well-formed  F,  f",  and  of  appropriate  length,  if  there  is  a  least  pair  (F';  rc)  such 
that  r  <  (r;  F';  F";  F"')nc,  then  /(F;  f")  =  (r';  rc);  if  there  is  no  (F';  rc)  such  that 
r  <  (F;  r r";  r'")rc  then  /(r;  r")  =  ns.  To  avoid  a  circular  proof,  we  cannot  yet  argue 
that  these  are  all  the  possibilities;  in  principle  there  could  be  an  infinite  chain  of  distinct  pairs 
. . .  <  (&3 ;  ic3)  <  (k2\  kc2)  <{k\\kc\)  such  that  for  all  i  we  have  r  <  (F;  A:,-;  F";  r'")tc,. 
Thus  we  will  not  use  this  simple  property  to  define  i;  instead  give  a  different,  more 
constructive,  definition  of  i  and  then  prove  that  the  i  defined  this  way  satisfies  the  simple 
property. 

Definition  5.8  (Interpretation  of  a  Refinement  Type)  Suppose  k  has  the  form 

(fci;  k\;  k”;  k'[')kc\  A  ...  A  (fcn;  k'n;  fc";  k™)kcn 

and  suppose  k  (Z  (t;  V;  t";  t"')tc  and  r  O  t  and  r"  d  t".  Then  we  define  i(k)(r;  r")  to 
be 

I  his  in  1  ...nandr  <  khandr"  =  k ^}. 
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We  extend  i  to  give  an  interpretation  to  generalized  refinement  types  by  defining 
z(ns)(r;  r ")  =  ns. 

For  example,  if  we  eliminate  some  of  the  syntactic  sugar  from  the  refinement  type 
tt  — » ff  A  Tiooi  — ►  tt  we  get  ( tt;  ff; ; )  mrrow  A  (T kao/;  tt; )  rarrow.  The  interpretation 
of  this  is  a  function;  if  we  pass  the  function  the  pair  (tt; )  consisting  of  the  sequence  of 
refinement  types  tt  with  length  1  followed  by  the  empty  sequence  of  refinement  types,  the 

def 

result  is  the  generalized  pair  (tt  A  T*^;  rarrow  A  rarrow).  This  has  the  same  information 
as  the  interpretation  we  had  in  Chapter  2. 

For  another  example,  we  can  compute  i((  tt ; ; ; )  tpred  A  (ff; ; ; )  fpred);  this  is  a  function 

which,  among  other  things,  maps  the  pair  (tt  A  ff;)  to  (;  tpred  A  fpred). 

We  also  give  an  example  using  the  datatype  mix.  The  refinement  type  (; ;  tt; )  tmix  A 
(; ;  T ini; )  Jmix  is  not  equivalent  to  any  simpler  refinement  type;  we  have 

*((; ;  tt; )  tmix  A  (; ;  T )  fmix)(;  tt)  =  (;  tmix), 

»((;;«;  )  tmix  A  (; ;  T4oo,; )  fmix)(;  ff)  =  ( ;fmix ), 
and 

z((; ;  tt; )  tmix  A  (;;  T M ; )  fmix)(;  T hool)  =  ns. 

After  updating  the  notation,  the  theorems  proved  about  i  in  Chapter  2  are  still  provable. 
The  only  real  difference  in  the  proofs  is  the  convolutedness  of  the  notation,  so  we  shall  omit 
the  proofs. 

The  new  version  of  Lemma  2.80  (z  Monotone  in  Second  Argument)  on  page  108  has 
two  parts,  because  the  mixed  type  arguments  are  treated  differently  from  the  negative  type 
arguments: 

Fact  5.9  (i(k)(r ;  r")  Monotone  in  r)  If 

r  i  <  r2 

andf\  C  t  and  r"  C  t"  and  k  C  (t;  V;  t";  t"')tc,  then 

i(k)(f  i;  r")  ■<  z'(fc)(r2;  f"). 

Fact  5.10  (z(fc)(r ;  f")  Respects  Equivalence  in  r")  If 


and  rdf  and  r"  C  t"  and  k  C  (t;  t';  t";  t"')tc,  then 


i(k)(r;r'{)zii(k)(r;r  "). 


250 


CHAPTERS.  POLYMORPHIC  REFINEMENT  TYPE  CONSTRUCTORS 


Lemma  2.81  (»  Monotone  in  First  Argument)  on  page  109  requires  little  change: 

Fact  5.11  (t  Monotone  in  First  Argument)  If 

k  <  p 

and  f  Ct  and  f "  (Z  t"  and  k  C  (f ;  V\  t";  tm)tc,  then 

t(A:)(r ;  r")  X  i(p)(r ;  r"). 


The  corollary  to  Lemma  2.81  (*  Monotone  in  First  Argument)  on  page  109  is  still 
simple: 

Fact  5.12  (Bound  on  Argument  to  t  Gives  Bound  on  t)  If 

k  <  (r ;  r';  rw;  ?'")rc 

then 

i{k)(f,r")  X  (?';rc). 

Using  the  facts  stated  above,  we  can  prove  the  following  generalization  of  Lemma 
2.26  (Tuple  Subtyping)  on  page  42  and  Fact  2.28  (Refinement  Constructor  Subtyping)  on 
page  45: 

Corollary  5.13  (Arbitrary  Constructor  Subtyping)  If(k)kc  <  {*)rc,  then  k  <  ¥  and 

def 

kc  <  rc. 


Proof:  Suppose  r  oc  r;  r';  r";  rm  and  k  oc  k;  k‘\  k";  k" .  By  Fact  5.12  (Bound  on 
Argument  to  i  Gives  Bound  on  *)  on  page  250  we  have 

i((I)£c)(r;  r")  X  (r';  rc).  (5.1) 


Thus  i((k)kc)(r;  r")  is  not  ns,  and  the  definition  of  i  gives 


and 


i((k)kc)(r;r")  =  (*';  kc), 
f  <  k, 

r"  =  k". 


From  (5.1)  and  the  definition  of  X  we  have 
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and 

def 

kc  <  rc.  (5.2) 

Theorem  2.21  (Subtypes  Refine)  on  page  36  holds  for  this  system,  so  there  is  a  V"  such 
that  k C  t"'  and  f"'  C  V".  Then  the  definition  of  <  for  sequences  gives  k  <  r.  This 
and  (5.2)  are  our  conclusion.  ^ 

We  state  the  generalizations  of  the  remaining  lemmas  and  theorems  from  Section  2.8  so 
a  determined  reader  will  be  able  to  reconstruct  the  details  of  the  reasoning  without  going 
astray.  Nothing  very  interesting  is  happening  here,  so  other  readers  can  skip  to  the  next 
section. 


Fact  5.14  ( i  Gives  an  Upper  Bound)  If 

i(k)(f-,r")^(f'-rc) 

and  k  C  (r ;  f r";  f"')tc  and  ¥'"  C  V" ,  then 

k  <  (r ;  r r  f"')rc. 

Fact  5.15  (Ordering  on  i)  If,  for  all  k  C  t  and  all  k"  C  t",  we  have 

i(r)(k\le")  <  i(p)(k;k"), 

and  r  d  (t ;  t'\  t i'")tc  and  p  C  (F;  t';  t"\  t'")tc,  then 

r  <  p. 

Fact  5.16  (i  Preserves  Information)  Suppose  that  r,  and  r2  both  refine  (t;  t'\  t";  i"')tc. 

Then  _  _  _ 

for  all  k\  C  t  and  k2Ct  and 

V[  c  t"  and  k"  C  t" 
we  have 

{k i  =  k2)  and  (A,  =  k2)  imply 
(t(ri)(fci;  fc")  «  i\r2)(k2,  fc")) 

if  and  only  if 

r\  =  r2. 


Definition  5.17  We  define  the  equivalence  class  of  a  generalized  refinement  type  rl  ( written 
C(r?))  to  be  the  set  {r?'  |  r?'  «  r?}. 

We  define  the  equivalence  class  of  a  generalized  pair  rr?  (written  C(rr?))  to  be  the  set 
{rrT  |  rr?'  «  rr?'}. 

We  define  the  equivalence  class  of  a  sequence  of  refinement  types  f  ( written  C(r))  to 
be  the  set  {¥'  |  r'  =  r  }. 
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Definition  5.18  We  define  the  set  of  equivalence  classes  of  refinements  of  an  ML  type  t 
(written  EC(t))  to  be  (C(r?)  |  r?  C  f }. 

We  define  the  set  of  equivalence  classes  of  refinements  of  a  pair  ( t\tc)(  written  EC(t\tc)) 
tobe{C(rrl)  \  rrl  C  (t;tc)}. 

We  define  the  set  of  equivalence  classes  of  refinements  of  a  sequence  i  (written  EC(i)) 
to  be  { C(r )  |  r  o  <}. 

We  shall  use  c  as  a  metavariable  standing  for  the  equivalence  class  of  some  refinement 
type,  c?  as  a  metavariable  standing  for  the  equivalence  class  of  some  generalized  refinement 
type,  cc 1  as  a  metavariable  standing  for  the  equivalence  class  of  some  generalized  pair,  and 
c  as  a  metavariable  standing  for  the  equivalence  class  of  some  sequence. 

Definition  5.19  IfrC(t;  t‘\  t";  tn,)tc  and  ccl  £  EC(V;  tc)  and  c  £  EC{t)  and  c"  £ 
EC(i")  then  we  write 

ccl  =  J(r)(c;  c") 

if  there  is  a  k  and  a  k"  in  c"  such  that 

ccl  =  C(t(r)(k;  k")). 


By  Fact  5.9  ( i(k)(r ;  r")  Monotone  in  r)  on  page  249  and  Fact  5.10  (i(k)(r;  r")  Respects 
Equivalence  in  r")  on  page  249,  for  all  r  we  know  that  J(r)  is  a  function. 

Fact  5.20  (I  Preserves  Equivalence)  Ifr  and  r'  refine  (t;  V;  t t'")tc  then 


if  and  only  if 

for  all  c  £  EC(t)  and  all  c"  €  EC(t ")  we  have  I(r)(c;  c")  =  I(r')(c;  c "). 

And  finally. 

Fact  5.21  (Finite  Refinements)  For  each  ML  type  u  we  have  EC(u)  is  finite. 

and,  once  we  define  type  inference,  the  same  simple  argument  for  principal  types  used  in 
Chapter  2  will  hold: 

Fact  5.22  (Principal  Refinement  Types)  If 

VR  I ~e:r 


then  there  is  a  k  such  that 


VR  he:k 


and  for  all  p  we  have 


VR  h  e  :  p  implies  k  <p. 
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5.4  Splitting 


Splitting  does  not  simplify  as  much  as  subtyping  did.  We  only  need  a  syntactic  change  to 
make  the  RCON-SPLIT  rule  in  Figure  2.5  on  page  48  accommodate  polymorphic  constructors: 


RCON-SPLIT: 


def 

re  x  sc 


(r)rc  x  {(r)jfec  |  kc  G  sc} 


None  of  the  other  splitting  rules  in  the  system  change:  in  particular,  the  TUPLE-SPLIT  rule 
does  not  change.  It  is  tempting  to  “generalize”  it  to  get  an  incorrect  rule  for  splitting 
polymorphic  types  where  all  the  arguments  are  positive: 


t  x  s 

BOGUS:  (: :  k\ , . . . ,  ki-ii fci+i |...  i km,  )rc  x 

{(■,;ki,...,ki.up,ki+l,...,km;)rc  \  p  6  a} 

This  incorrect  rule  would  allow  us  to  use  T^/  x  {tt,ff}  to  derive  T  hool  ev  x  {tt  ev,ff  ew}. 
This  is  not  sound;  for  example,  the  value  cons  (true,  cons  (false,  nil))  has  the  type 
T  ev  but  it  does  not  have  either  of  the  types  tt  ev  or  ff  ev. 

To  make  type  inference  tractable,  we  assume  that  if  a  refinement  type  constructor  splits, 
it  has  no  negative  or  mixed  type  arguments.  Formally, 

Assumption  5.23  (Split  Positive)  If  rc  xf  {rc\ , . . . ,  rcn },  then  arity(rc)  has  the  form' 
(0;  x;  0;  y)  for  some  nonnegative  integers  x  and  y. 

Without  this  assumption,  there  might  be  splittable  refinement  types  that  can  only  be  ex¬ 
pressed  as  an  intersection  of  other  refinement  types;  for  example,  we  could  have  the 
declaration 

datatype  (a;;;)  doublepred  dl  of  a  — *  bool  |  Pred2  of  a— >  bool 

rectype  (a;;;)  tpredl2  =  P*  of  a—*  tt  I  Pred2  of  a—*tt 
and  (a; ; ;  )  tpredl  =  Predl  of  a  — *  tt 
and  (a; ; ; )  tpredl!  =  Pred2  of  a—>tt 

and  (a;;;)  fpred!2  =  Predl  of  a—^ff  I  Pred2  of  a—*ff 

where  tpredl2  xf  {tpredl ,  tpred2}.  Then  we  might  have  to  determine  that  the  principal 
split  of  the  refinement  type  ( tt ; ; ; )  tpredl2  A  (ff; ; ; )  fpredl2  is 

{(«; ; ; )  tpredl  A  (ff; ; ; )  fpredl2 ,  (tt;;;)  tpred2  A  (ff;;;)  fpredl2). 

In  general,  it  seem  that  we  might  have  to  search  over  all  of  the  supertypes  of  the  type  we 
start  with  to  find  splits,  and  then  combine  these  to  get  the  principal  split.  The  assumption 
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above  saves  us  from  that;  with  the  assumption,  all  splittable  types  are  equivalent  to  a  type 
of  the  form  {¥)rc  where  rc  has  a  predefined  split. 

The  theorems  Theorem  2.31  (Splits  Are  Subtypes  I)  on  page  49,  Corollary  2.32  (Split 
Types  Refine  I)  on  page  51,  Fact  2.33  (Splits  Are  Subtypes  II)  on  page  51,  and  Fact  2.34 
(Split  Types  Refine  II)  on  page  51  continue  to  hold  for  the  new  system.  To  get  Fact  2.35 
(Splits  of  Arrows  are  Simple)  on  page  5 1  to  hold  in  the  new  system,  we  need  to  assume  that 
mrrow  has  no  interesting  splits: 


Assumption  5.24  (Arrow  Does  Not  Split)  There  is  no  sc  such  that  rarrow  sc. 

Fact  2.37  (Splits  are  Nonempty)  on  page  5 1  continues  to  hold,  as  do  Lemma  2.43  (Split 
Intersection)  on  page  54,  Lemma  2.45  (Principal  Split  Implies  Useless  Splitting  Fragments) 
on  page  58,  and  Lemma  2.46  (Fragments  of  Principal  Split  have  Useless  Splits)  on  page  58. 


5.5  Refinement  Type  Inference 


The  assumptions  we  make  about  value  constructors  now  have  type  variables  embedded.  To 
say  that  a  constructor  c  maps  values  with  type  r  to  values  with  type  (a)rc,  we  write 


def  ,  =  s 

c  :  r  <—*  (a)rc. 


This  notation  implies  that  c  maps  all  instances  of  r  to  the  corresponding  instances  of  (5  )rc. 
Only  two  refinement  type  inference  rules  appearing  in  Figure  2.6  on  page  60  and  updated 
on  page  4.2  have  to  change  to  accommodate  this: 


CONSTR-TYPE: 


def  ,  =  . 

c  :  r  <—*  (a)rc 
VR  H  e  :  [f/5]r 
¥  □  t 

VR  h  c[f]  e  :  (F)rr 


VR  I-  e0  :  (r,)rci  A  ...  A  (rm)rcm 
r  C  u 

rtom(VR)  t- (case  e0  of  cj  =>  ex  I  ...  1  Cn  ->  e„  end:u)  ::  u 

for  all  i  in  1 . . .  n  and  all  i*i , . . .  ,rm,  whenever 
CASE-TYPE:  ......  ,  def 

for  all  j  m  1  ...m  we  have  c*  :  rj  <—>  {a)rcj 

we  have 

_ VR  I-  ej  :  ([Fi/g]ri  A  ...  A  [Fm/5]rm)->r _ 

VR  h  (case  e0  of  cj  =>  e[  1  ...  I  Cn  =>  en  end :u)  :  r 


The  CONSTR-TYPE  rule  is  fairly  intuitive.  To  infer  that  a  value  constructor  returns  a 
polymorphic  type  (F)rc,  we  check  that  ¥  is  well-formed,  that  the  value  constructor  maps 


5.5.  REFINEMENT  TYPE  INFERENCE 


255 


some  type  r  to  rc,  and  that  the  argument  of  the  value  constructor  has  an  appropriate 
instance  of  r  as  its  type.  For  example,  we  can  use  this  rule  to  conclude  that  the  expression 
cons[6oo/]  (tru«[]  (),  nil[6oo/]  ())  has  the  type  (;«;;)  od,  assuming  we  have  the 
premises 

cons  (a  *  (;  a; ; )  et?)  ^  (;  a; ;  )  od, 

•H(true[j  (),  nil[6oo/j  ()):«*(;  tt; ;)  evt 
and 

tt  c  bool. 

The  CASE-TYPE  rule  is  somewhat  more  complex;  the  difficult  part  is  the  premise  begin¬ 
ning  with  “for  all  i  in  1 . . .  n...”.  An  intuitive  reasonable  reading  of  this  complex  premise 
of  CASE-TYPE  is 

for  all  branches  of  the  case  statement  and  all  inputs  to  the  constructor  in  that  branch,  if 

giving  an  input  to  the  constructor  for  this  branch  yields  the  type  of  the  case  object 
then 

giving  that  input  to  the  type  of  this  branch  must  yield  the  type  of  the  case  statement. 
We  can  translate  this  into  the  formal  notation  used  in  the  inference  rule  as  follows: 

e  “For  all  branches  of  the  case  statement”  becomes  “for  all  i  in  1 . . .  n”. 

e  “The  case  object”  is  “e0”. 

e  “The  type  of  the  case  object”  is  (Fijrc!  A  ...  A  (Fm)rcm. 

e  “The  constructor  in  that  branch”  is 

•  “For  all  inputs  to  the  constructor  in  that  branch”  becomes  “for  all  r  \ , . . . ,  rm”.  Roughly 
speaking,  the  input  to  the  constructor  is  [F i  /a]rj  A  ...  A  [rm/5]rm. 

•  “Giving  an  input  to  the  constructor  of  this  branch  yields  the  type  of  the  case  object” 
translates  approximately  to 

“Ci  :  ([Fi/a]r,  A...  A  [Fm/S]rm)  — >((F1)rc1  A  ...  A  (Fm)rcm)”. 

However,  this  is  not  well  formed,  since  constructors  by  themselves  are  not  expres¬ 
sions.  Doing  this  one  component  at  a  time  yields  the  still  ill-formed  translation 

“for  all  j  in  1 . .  .m  we  have  c,- :  [Fj/Sjr,-  — >(Fm)rcm”. 

We  can  make  a  well-formed  translation  without  changing  the  meaning  in  any  impor¬ 
tant  way  by  omitting  the  instantiation  in  the  type  of  c^;  this  yields 

“for  all  j  in  1 ...  m  we  have  d?f  r j  <— *  (s)nc/\ 
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•  “The  type  of  the  ca»«  statement”  is  simply  “r” 

•  “This  branch”  is  “ej” 

•  “Giving  that  input  to  the  type  of  this  branch  must  yield  the  type  of  the  case  statement” 
translates  to  “VR  h  e, :  ([?i/5]ri  A  ...  A  [Fm/5]rfB)  -+  r” 

For  example,  if  we  use  the  pred  datatype  introduced  on  page  240,  then  the  expression 

case  Pred  (fn  x-.bool  =>  x[])  of 
Pred  =*>  fn  f :  bool  — >  bool  =>  f[] 
end:  bool  — >  bool 

has  the  type  tt  —*  tt  A  ff  —*  ff  because  the  following  premises  hold: 

•  h  Pred  (fn  x:  bool  =>  xfl)  :  ( tt\ ; ; )  tpred  A  ( ff ; ; ; )  fpred, 

tt—*tt  Aff—*ff  [I  bool  — >  6oo/, 

•  h  (case  . . .  end:  bool  — »  bool)  ::  bool  —*  bool , 
and 

Pred  df  (a  — ►  tt)  <— »  (a; ; ; )  tpred  and 

Pred  d?f  (a  -» ff )  <-»  (a; ; ; )  ^>red  imply 
•  h  f  n  f :  bool  — »  bool  =>  f  (j :  tt  -+tt  A  ff  —*  ff 

5.5.1  Positions  of  Type  Variables 

We  need  to  make  some  assumptions  about  how  the  type  variables  appear  in  the  d?f  relation. 
First  we  must  assume  that  the  type  variables  appear  in  the  proper  position;  for  example,  if 
a  is  in  the  positive  position  of  a,  and  c  :  r  <-+  (a)rc,  then  [k/a]r  should  become  larger 
as  k  becomes  larger.  We  will  give  a  formal  definition  of  this  assumption  below,  but  first  we 
will  give  a  concrete  example  where  refinement  type  inference  is  unsound  if  the  assumption 
does  not  hold. 

We  will  assume  a  datatype  (a; ; ; )  box  with  one  negative  type  argument,  one  refinement 
T  and  one  value  constructor  Box.  We  shall  assume  the  constructor  Box  has  these 
behaviors: 

Box  ::  a  <— ►  (a; ; ; )  box 
Box  d:f  a  <-»  (a; ; ; )  T 

Since  a  occupies  the  first  position  in  the  quadruple  (a; ; ; )  and  the  first  position  is  negative, 
this  behavior  for  Box  violates  the  assumption  we  are  discussing:  as  a  type  substituted  for 
a  gets  larger,  the  type  a  on  the  left  hand  side  of  the  <— ►  also  gets  larger,  but  the  type 
(a; ; ; )  on  the  right  side  gets  smaller. 
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We  will  also  use  the  value  constructor  true  for  the  booleans.  If  we  do  not  use  any  of 
the  convenient  abbreviations  we  have  introduced  so  far,  true  has  these  behaviors: 

true  If  (; ; ; )  ttuple0  ^  (; ; ; )  bool 

true  ‘‘f  (; ; ; )  rtuplc0  *->(;;;)« 

Using  the  abbreviations,  we  can  make  these  look  more  familiar: 

def  ...  ,  , 

true  ::  tumt  «— ►  bool 

def 

true  :  runtt  tt 

def 

We  will  also  use  the  assumption  that  <  tt. 

In  this  context,  we  can  now  show  that  the  expression 

case  Box[Aoo/;;;]  (true  ())  of 
Box  3>  fn  x:  bool  *>  x[] 
end :  bool 

has  the  refinement  type  Since  this  expression  evaluates  to  true  (),  and  true  () 

does  not  have  the  type  J-too/,  our  type  system  is  not  sound  with  the  assumptions  we  have 
made  so  far. 

First  we  find  a  type  for  Boxftt; ; ;  ]  (true  ()).  The  expression  true  ()  obviously  has 
the  type  tt.  By  constr-TYPE  and  the  assumed  behavior  of  Box,  the  expression 

Box[«;;;]  (true  ()) 

then  has  the  type  ( tt ; ; ; )  T^,.  Now  we  can  do  the  step  where  we  lose  soundness:  since 
i-4oo/<  tt,  by  RCON-SUB  we  have  (tt; ; ;  )  T*,,  <  (lw; ; ; )  T 4ax;  thus  by  WEAKEN-TYPE 
we  can  infer  that  Box[i<; ; ;  ]  (true  ())  has  the  type  (±hooi ; ; ; )  T^,. 

Now  we  can  continue  to  find  a  type  for  the  case  statement  as  a  whole.  This  is  a  use  of 
CASE-TYPE  with  the  premises 

•hBox[tt;;;]  (true  ()) :  (-L»„oi; ; ; )  T4ox, 

bool , 

■  l~  case  ...  end: bool ::  bool , 
and 

Box  :  a— »(a;;;)  T***  and  •  t-  fn  x:bool  =>  x[]  — ♦  J-4oof- 

The  conclusion  of  CASE-TYPE  is  •  h  (case  ...  end:  bool) :  tt.  As  discussed  above,  if  this 
expression  has  this  type,  then  type  inference  is  not  sound. 

To  prevent  this,  we  need  to  define  what  it  means  for  a  type  variable  to  be  positive, 
negative,  mixed,  or  absent  from  a  refinement  type,  and  we  will  require  that  whenever 
c  df  r  «-» (s)re,  the  positive  type  arguments  of  rc  are  positive  in  r,  the  negative  ones  are 
negative,  and  so  forth.  The  definition  is  somewhat  wordy,  but  very  regular. 


258 


CHAPTERS.  POLYMORPHIC  REFINEMENT  TYPE  CONSTRUCTORS 


Definition  525  (Negative,  Positive,  Ignored)  We  say  a  type  variable  a  is  negative  (or 
positive  or  ignored)  in  a  list  of  refinement  types  f  if  a  is  negative  (or  positive  or  ignored, 
respectively)  in  each  element  off. 

A  type  variable  a  is  negative  in  a  refinement  type  r  if 

•  r  oc  rt  A  r2  and  a  is  negative  in  both  r\  and  r2,  or 

•  r  ex  0  where  0  ^  a,  or 

•  r  <x  (r  i;  r2;  r3;  r4)rc  and  a  is  positive  in  f  lt  negative  in  f2,  and  ignored  in  r3. 

A  type  variable  a  is  positive  in  a  refinement  type  r  if 

•  rariArj  and  a  is  positive  in  r3  and  r2,  or 

•  r  oc  0  (whether  or  not  a  =  0),  or 

•  r  oc  (r  i;  r2;  r3;  r4)rc  and  a  is  negative  in  r  j,  positive  in  f2,  and  is  ignored  in  r3. 

A  type  variable  a  is  ignored  in  a  refinement  type  r  if 

•  t  oc  ri  A  r2  and  a  is  ignored  in  both  rx  and  r2,  or 

•  r  oc  0  where  a  f  0 

•  r  oc  (Ft;  r  2;  r3;  r4)rc  and  a  is  ignored  in  f\,  f2,  and  r3.  (It  does  not  matter  whether 
it  appears  in  r4.) 

Definition  5.26  (Varies  properly)  We  say  that  a  quadruple  of  type  variables  a,;  a2;  a3;  a4 
varies  properly  in  a  refinement  type  r  if  all  the  variables  in  ai  are  negative  in  r,  all  variables 
in  a2  are  positive  in  r,  and  all  variables  in  a4  are  ignored  in  r. 

Assumption  5.27  (Variance)  If  c*?  r  <-*  {a)rc,  then  5  varies  properly  in  r. 

Fact  5.28  (Variant  Weakening)  //§  varies  properly  in  r,  and  f  <f  ,  and  rut,  then 

[r/a]r  <  [r  /a]r. 


The  proof  is  by  induction  on  r. 
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5.5.2  Intersection  and  Polymorphism 

In  this  Subsection  we  will  make  an  assumption  that  eliminates  the  need  to  use  RCON-and- 
ELIM-SUB  to  reason  about  types  for  constructors.  The  assumption  is: 

Assumption  5.29  (Predefined  Intersection  Distributivity)  For  all  value  constructors  c, 

if 

def  .  —  . 

c  :  r  <— >  (a)rc 

and 

c  :  r  (a)rc 

and  S  has  the  form  (ai;  a2\  03;  04),  then  for  any  well-formed  k  and  k'  of  appropriate 
length,  we  have 

[A /aflr  A  [k' <  [A  A  k' laffr  A  r'). 


Now  we  can  explain  which  uses  of  RCON-and-ELIM-sub  this  makes  unnecessary.  Sup¬ 
pose  an  expression  e  has  the  type  [A  jaflr  A  [A  /afpr'.  By  WEAKEN-TYPE  it  has  each  of 
the  types  [A  /a2]r  and  [A  /a2]r'.  Then  we  can  use  CONSTR-TYPE  twice  to  determine,  for 
an  appropriate  I,  that  c[f]  e  has  each  of  the  types  (aj;  A;  53;  a4)rc  and  (ai;  k';  ay,  a4)rc'. 
Then  AND-INTRO-TYPE  tells  us  it  has  the  type  (ai;  A;a3;a4)rc  A  (a^  A  ;a3;a4)rc\  and 

_  _ /  dcf 

WEAKEN-TYPE  and  RCON-AND-ELIM-SUB  tells  US  it  has  the  type  (a,;  AaA  ;a3;  a4)(nc  A  rc'). 

Predefined  Intersection  Distributivity  tells  us  we  can  come  to  the  same  conclusion- 
without  usin^  RCON-AND-ELIM-SUB.  First  we  use  WEAKEN-TYPE  to  conclude  that  e  has  the 
type  [AaA  /a2](r  A  r');  then  by  Assumption  2.52  (Constructor  Argument  Strengthen) 
on  page  67  and  Assumption  2.51  (Constructor  And  Introduction)  on  page  67  we  have 

c  :  r  A  r' c— *  (s)(rc  A  re'),  and  then  by  CONSTR-TYPE  we  know  that  c[i ]  e  has  the  type 

(aj;  A  A  k';ay,a4)(rc  A  rc'). 


Having  an  assumption  that  makes  it  unnecessary  to  use  certain  inference  rules  with 
constructors  is  something  we  have  done  before.  For  example.  Assumption  2.5 1  (Constructor 
And  Introduction)  on  page  67  makes  it  unnecessary  to  use  and-intro-TYPE  in  some  cases, 
and  Assumption  2.52  (Constructor  Argument  Strengthen)  on  page  67  and  Assumption  2.53 
(Constructor  Result  Weaken)  on  page  67  make  some  uses  of  weaken-type  unnecessary. 
All  these  assumptions  eliminate  the  need  to  use  refinement  type  inference  to  infer  types  for 
constructors  from  the  case-  1 YPE  rule.  Perhaps  it  would  be  possible  to  make  a  system  with 
fewer  assumptions  but  a  more  complex  proof  if  we  used  refinement  type  inference  for  the 
constructors  in  case  statements;  but  that  is  beyond  the  scope  of  this  thesis. 

There  are  no  interesting  changes  to  the  theorems  asserting  compatibility  between  re¬ 
finement  type  inference  and  ML  type  inference. 
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5.6  Soundness 


The  statement  and  proof  of  Lemma  4.4  (Environment  Modification)  on  page  235  do  not 
change.  The  new  version  of  Lemma  2.67  (Piecewise  Intersection)  on  page  84  needs  to  make 
nontrivial  use  of  Predefined  Intersection  Distributivity;  we  will  restate  the  lemma  and  show 
how  it  depends  on  Predefined  Intersection  Distributivity  before  we  show  the  modifications 
to  the  proof. 


Lemma  5  JO  (Piecewise  Intersection)  If 

for  alii  in  1  ...m  we  have  •  H-  v  :  ( k  i)lcci 

and 

(ki)kci  A  ...  A  ( km)kcm  <  (Fi)rci  A  ...  A  (F„)rc„ 
then  for  all  j  in  1 ...  n  we  have 

•H-i) :  (Fi)rcj. 


(5.3) 

(5.4) 


Without  Predefined  Intersection  Distributivity,  this  is  false.  For  a  counterexample,  suppose 
we  have  the  declarations 

datatype  (a;;;)  d  =  C  of  bool— *  a 
rectype  (a;;;)  z  =  C  ( tt-*a )  I  C  {ff->a) 


Then,  if  it  were  not  for  Predefined  Intersection  Distributivity,  we  could  use  a  straightforward 
procedure  to  determine  that  C  has  the  behaviors 

C  d?f  (tt-*a)  «-*  (a;;; )  z 

and 

c" 

but  not 


C  :  (_L* -*  a)  <->  (a; ; ; )  z. 

Then  these  premises  of  Piecewise  Intersection  could  be  true: 

•H~C(6oo/j  (fn  x:bool  =>  x[j) :  (tt’, ; ; )  z 

•  H-  C[6ooI]  (fn  x:bool  =>  x[])  :  (ff; ; ; )  z 
(«;;;)zA(Jf;;;)z  <  (i-4*ot;;;)z 


but  we  would  not  have  the  conclusion 


•  H-  C[6ooI]  (fn  x:  bool  =>  x(]) :  (±^/; ; ; )  z 
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because  the  only  way  to  derive  this  conclusion  uses  WEAKEN-TYPE  as  the  last  inference, 
and  the  meaning  of  H-  specifically  excludes  WEAKEN-TYPE  as  the  last  inference. 

Proof:  Byinductiononthederivationof(A:i)fcciA...A(fcm)tam  <  (Fi)rci  A. .  ,A(f„)rcn. 
Case:  RCON-SUB.  Then  m  =  n  =  1  and  the  premises  of  RCON-SUB  are  fci  <  rj  and 

def 

kci  <  rc\.  From  here  we  take  cases  on  the  form  of  v. 

SubCase:  v  <x  c[tl ]  v'.  The  last  inference  of  •  H-  v  :  (k  i  )kct  must  be  CONSTR-TYPE  with 
the  premises 

c  d?f  r  I— >  (S)ifeci , 

•  I-  v' :  [Ii/5]r, 

and 

k\  C  l. 

def 

By  Assumption  2.53  (Constructor  Result  Weaken)  on  page  67  and  kc\  <  rcj,  we  have 

c  r  (5)rci.  (5-5) 

By  Assumption  5.27  (Variance)  on  page  258  we  know  that  S  varies  properly  in  r.  Thus  Fact 

5.28  (Variant  Weakening)  on  page  258  gives  [fci/Sjr  <  [f  i/Sjr,  and  then  WEAKEN-TYPE 
gives 

■Hd':  [Fi/!j]r 


(-  c[t]  v'  :  (r,)rci, 


and  CONSTR-TYPE  and  (5.5)  give 


which  is  our  conclusion. 
SubCase:  Otherwise.  Omitted. 


Case:  rcon-and-ELIM-sub.  Then  (5.4)  has  the  form 


(fci;  k2;  ky,  k4)kc  1  A  (k i;  k'2;  ky  k4)kc2  <  {ky  k2  A  k'2\  ky  k4 )(kc\  A  kc2 ) 
From  here  we  shall  take  cases  on  the  form  of  v. 


SubCase:  v  oc  c[t  ]  v'.  Then  (5.3)  says 


H—  c[t j  v' :  (k\)kc\ 
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and 

•  H-c[fj  v' :  (U2)kc2. 

The  last  inferences  of  each  of  these  must  be  constr-type  with  the  premises 

c  k\  «— ►  (5)ibci 

•  I-  v' :  [E t/s]fc, 

Ei  C  l 

c  d?f  hi  *-»  (a)ic2 

•  I-  w' :  [fc2/a]&2 

j2ci 

Then  and-intro-TYPE  gives 

•N':  [fci/5]fei  A  [&2/5]fc 2. 

Suppose  5  has  the  form  a);  02;  03;  <*4;  then  Assumption  5.29  (Predefined  Intersection 
Distributivity)  on  page  259  gives 

[*2/«2]*i  A  [k'2/a2}k2  <  \k2  A  k'2/a2)(ki  A  kj). 

Using  Fact  4.2  (Type  Substitution  Preserves  Subtyping)  on  page  233  on  this  gives 

A  [I2/S]As2  <  [?,/5](/s,  A  kj). 

Then  weaken-type  gives 

•h  u':  [Fi/S](fci  A  *4). 

dcf 

Assumption  2.18  (and-intro-<)  on  page  34  and  Assumption  2.52  (Constructor  Argument 
Strengthen)  on  page  67  give 

c  dff  (ki  A  kz)  t->  (5)(fcci  Af  fcc2), 
and  then  constr-type  gives 

•  I-  c[</]  v ■  :  (r )( Acx  A  fcc2), 

which  is  our  conclusion. 

SubCase:  Otherwise.  Omitted. 

Case:  Otherwise.  Omitted.  □ 

Lemma  2.68  (Subtype  Irrelevancy)  on  page  88,  Theorem  2.69  (Splitting  Value  Types) 
on  page  89,  and  Fact  4.5  (Refinement  Type  Substitution)  on  page  236  continue  to  hold 
with  no  interesting  changes.  The  version  of  Value  Substitution  as  revised  in  Chapter  4 
on  page  236  also  has  only  notational  changes.  Refinement  Type  Soundness  as  revised  in 
Chapter  4  on  page  237  has  no  interesting  changes  either,  the  only  nontrivial  changes  needed 
to  deal  with  polymorphic  type  constructors  are  in  the  lemmas,  not  in  the  main  theorem. 
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The  changes  in  this  chapter  only  affect  the  cases  of  the  type  inference  algorithm  that  deal 
with  constructors  and  case  statements.  The  changes  required  to  the  algorithms  are  intuitive; 
the  changes  required  to  the  proofs  are  simple,  except  the  proof  that  the  algorithm  derives 
principal  types  for  case  statements  is  awkward. 

Since  types  have  become  more  general,  we  need  to  generalize  some  of  the  utility 
functions  used  by  infer.  First,  we  make  versions  of  allref s  that  find  refinements  for  a 
vector  or  quadruple  of  refinement  types: 

fun  vallrefs  t  = 

{r  |  length  r  =  length  t  and 

for  i  €  1 . .  .length  t  we  have 
r{i}  G  allrefs  t{i}} 
fun  qallrefs  £f,  f  2i  ^4  = 

{ri;r2;  r3;r4  | 

Fi  €  vallrefs  t\  and 
r2  €  vallrefs  i2  and 
rj£  vallrefs  1 3  and 
r4  €  vallrefs  £4} 

The  new  definition  of  the  interpretation  i  works  for  arbitrary  refinement  types,  instead  of 
just  functions.  We  call  the  function  for  computing  this  iconstr  by  analogy  with  the  if  n- 
function  defined  on  page  120.  In  this  definition,  iconstr  r?  (p;  p")  (£;  t")  computes 
i(r?)(p;  p"),  assuming  that  p  □  t  and  p"  C  t"  and,  for  some  tc,  V,  and  t"  we  have 
r?  C  (?;  t';  t";  This  definition  assumes  that  Afn  has  been  revised  to  work  on 

generalized  pairs,  and  that  vsubtypep  is  a  generalization  of  subtypep  that  works  on 
vectors;  both  of  these  are  easy  to  write. 


fun  iconstr  r?  (p;p")  (?;?”)  = 


if  r?  =  ns  then  ns 
else 

let  val  (r  t;  r',;  r";  r"')rcj  A  . . .  A 
in 


r";r"')rc* 


r? 


Afn  {(f'h-,rch)  | 

h  €  1 ...  71  and  vsubtypep  p  fh  t  and 
vsubtypep  p"  rJJ  t"  and  vsubtypep  r p"  t"} 

end 


It  is  easy  to  give  an  alternative  definition  of  the  old  function  if  n  in  terms  of  iconstr. 
Here  ifn  r?  p  t  evaluates  to  i(r?)(p),  using  the  old  definition  of  i  from  Chapter  2, 
assuming  that  p  C  t  and  for  some  u  we  have  rl  \zt—*u. 
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fun  ifn  r?  p  t  * 

case  iconstr  r?  (p; )  (t; )  of 
ns  *>  ns 
I  (fc;  rarrow)  =>  fc 

We  also  define  a  utility  function  deval  that  de-e  valuates  a  constructor,  more  specifically, 
if  c  d;f  r  <— >  (a)rc,  then  there  is  some  type  equivalent  to  r  in  deval  c  rc.  This  is  used 
only  in  the  case  of  infer  for  case  statements  that  appears  below.  Because  there  are  finitely 
many  possible  inputs  to  deval,  it  can  be  evaluated  quickly  by  table  lookup  at  type  inference 
time.  The  implementation  does  this. 

fun  deval  c  rc  = 

let  val  u  =  the  unique  u  such  that  c  ::  u  «— ♦  {a)tc 
in 

{r  |  r  €  allrefs  u  and  c  :  r  ( a)rc } 

end 

The  new  cases  of  the  infer  algorithm  are: 

fun  infer  VR  (c[£]  e')  = 

let  val  k ?  =  infer  VR  e' 

val  t  =  the  unique  t  such  that  c  ::  t  <-*  tc 
val  s  =  allrefs  ( t ) 
in 

Afn  {(F)rc  |  ¥  6  s  and  for  some  r  €  allrefs  t  we  have 
r  <—>  (a) rc  and  subtypep  kl  ([F/a]r)  £} 

end 

I  infer  VR  (e  as  (case  e<j  of  C]  =>  e\  1  ...  I  c„  =>  en  end:f))  = 
if  not  rtom(VR)  h  e  ::  t  then  ns 
else  let  val  r?  =  infer  VR  eo 

val  u  -  the  unique  u  such  that  rtom(VR)  I-  e0  ::  u 
in  if  r?  =  ns  then  ns 

else  let  val  (Fi)rei  A  ...  (¥m)rcm  -  rl 

fmx  seq  h  =  (deval  c/,  rc i  x  ...  x  deval  ch  rcm) 
in 

sjoinf  t 

{ifn  (infer  VR  eh,  A  . . .  A  [Fm/l]rm)  u  | 

h  €  1 . . .  n  and  (tm  , . . . ,  ) e  (seq  h)} 

end 

end 

A  full  proof  of  this  would  require  replacing  two  of  the  cases  in  each  of  the  proofs  of 
Theorem  2.100  (Infer  Returns  Some  Type)  on  page  145,  Theorem  2.101  (Infer  Returns 


5.7.  DECIDABILITY 


265 


Principal  Type)  on  page  151,  and  Theorem  2.102  (Infer  Terminates)  on  page  160.  Most  of 
these  new  cases  would  be  very  similar  to  the  cases  they  replaced,  so  we  shall  omit  them. 
The  exception  is  the  case  of  Infer  Returns  Principal  Type  for  case  statements,  which  we 
give  below,  after  a  lemma. 

Before  we  can  prove  that  the  algorithm  for  inferring  types  for  case  statements  returns 
a  principal  type,  we  must  show  that  as  the  refinement  type  of  the  case  object  becomes 
stronger,  the  type  inferred  for  the  case  statement  as  a  whole  becomes  stronger.  To  state 
this  formally,  we  speak  in  terms  of  the  premises  of  CASE- type: 


Lemma  531  (Case  Statement  Body)  If 


(ri)rci  A  ...  A  (rm)rcm  <  (ki)kci  A  ...  A  ( kn)kcn 
and,  for  all  k\ , . . . ,  kn  we  have 


and 

then 


for  all  h  in  1 ...  n  we  have  c  :  kh"—*  ( a)kcn 
implies 

VR  h  e  :  ([fci/5t]&i  A  ...  A  [fcn/ajfc*)  — 

for  all  j  ini  ...m  we  have  c  d?f  r  j  <-+  (ziz  )rcj, 
VR  h  e  :  ([ri/a]rj  A...  A  [rm/5]rm)  -*r. 


(5.6) 


(5.7) 


(5.8) 


The  proof  is  not  particularly  interesting,  but  it  is  long  enough  that  it  was  a  nuisance  to 
discover,  so  we  include  it  here. 

Proof:  Suppose  that  kh  has  the  form 


kh;klkl-k: 


and  rj  has  the  form 
and  a  has  the  form 


a;  o' ;  a";  o'", 

and  let  p  abbreviate  (^i)rci  A ...  A  (fm)rcm.  By  Fact  5.12  (Bound  on  Argument  to  i  Gives 
Bound  on  *)  on  page  250  and  (5.6), 

for  h  G  1 ...  n  we  have  i(p)(  k  h-,k';)^(k'h;kch).  (5.9) 


Define 


a(h)  =  {j  €  1  ...m  |  kh  <  r,  and  k"h  =  r"}.  (5.10) 
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Then,  by  definition  of  i  and  (5.9), 

for  h  £  l...nwe  have  A{(r  rvj)  |  j  £  a(h)}  X  ( k'h ;  kch) 

which  implies 


and 


for  h  £  1 ...  n  we  have  A {r '•  |  j  £  a(A)}  <  kh 


dcf  #  dcf 

for  h  £  1 ...  n  we  have  A  {rcj  |  j  £  s(h)}  <  ken . 


(5.11) 


(5.12) 


We  can  use  (5.8)  and  Assumption  2.52  (Constructor  Argument  Strengthen)  on  page  67  to 
get 


for  h  £  1 . . .  n  and  all  j  in  a(h)  we  have  c  A{rj  |  j  £  s(h)}  <— >  (a  )rcj 
and  then  Assumption  2.51  (Constructor  And  Introduction)  on  page  67  gives 

_  (jgf 

for  h  £  1  ...n  we  have  c  :  A{rj  |  j  £  a(h)}  «— ►  (a)(  A{ncj  |  j  €  *(&)}) 
and  Assumption  2.53  (Constructor  Result  Weaken)  on  page  67  with  (5.12)  then  gives 


for  k  €  1 .  ..n  we  have  c ^  A{rj  |  j  £  a(h)}  <— ►  (a)ifcc/,. 

Define  kh  to  mean  A{rj  |  j  £  a(h)}.  Then  by  (5.7),  we  have 

VR  H  e  :  A  ...  A  [^n/Bt]fcn)-»r. 

The  remainder  of  the  proof  consists  of  showing  that 

{[ky/a]ki  A...  A  [In/alfcnJ-^r  <  ([F,/a]r,  A  ...  A  [rm/a]rm)  -> r. 

Once  we  prove  this,  we  can  use  WEAKEN-TYPE  with  (5.14)  to  get  our  conclusion. 

By  Assumption  5.27  (Variance)  on  page  258,  for  h  £  1 . . .  n  and  all  j  £  a(h)  we  have 
a  varies  properly  in  r,.  By  definition  of  a(h),  we  have 


(5.13) 


(5.14) 


and 

By  SELF-SUB, 


for  h  £  1 ...  n  we  have  j  £  s(h)  implies  kh  <  rj 
for  h  £  1 ...  n  we  have  j  £  a(h)  implies  k"h  =  f". 


for  h  £  l ...  n  we  have  j  £  a(h)  implies  r'  <  r^. 

Thus  by  the  definition  of  <  for  quadruples  we  have 

for  h  £  1 . . .  n  and  all  j  £  a(h)  we  have  fj  <  kh\  r'j;  A*;  A™. 

Then  Fact  5.28  (Variant  Weakening)  on  page  258  gives 

for  h  £  1 ...  n  and  all  j  £  a(h)  we  have  [Fj/5]rj  <  (A*;  r'-;  a£;  A|[7^]rj- 
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Then 

for  h  E  1 ...  n  we  have 

A{[?i/5]r,J  j  e  s(h)}  <  (5.15) 

A{[fefc;  rV  kuh ;  k"/^  I  3  €  <&)} 

because  each  element  of  the  set  on  the  left  hand  side  is  a  subtype  of  the  corresponding 
element  of  the  set  on  the  right  hand  side. 

It  is  easy  to  use  induction  to  generalize  Assumption  5.29  (Predefined  Intersection 
Distributivity)  on  page  259  to  apply  when  more  than  two  refinement  types  are  involved  in 
the  intersection;  thus  we  have 

for  h  E  1 ...  n  we  have 
A{[F'/a]ri  |  j  E  s(h)}  < 

[A{r'  |  j  €  a(h)}/a,](A{rj  |  j  E  3(h)}) 

Then  Fact  5.28  (Variant  Weakening)  on  page  258  used  with  (5.1 1)  gives 

for  h  E  1 ...  n  we  have 

[A{F$  |  j  E  s(h)}/a'](A{rj  j  j  E  s(h)})  <  [fe'fc/a](A {r*  |  j  E  3(h)}). 

Then  TRANS-SUB  applied  to  these  gives 

for  he  1 ...  n  we  have  A{[r  '•/a'jrj  |  j  E  s(h)}  <  [k  'h/a'}(A{rj  |  j  E  s(h)}). 

By  Fact  4.2  (Type  Substitution  Preserves  Subtyping)  on  page  233,  this  implies 
for  h  e  1 ...  n  we  have 

[kh-  IJ;  * '"/a; «"'](A{(F' /a,]ri  |  j  E  s(h)})  < 

[kh;  kl  k:/a;ct';a'"}[k,h/a')(A{rj  \  j  E  s(h)}), 


and  the  definitions  of  substitution  and  kh  then  give 
for  h  E  1 ...  n  we  have 

A {[kh;  r'-;  k"h\  k™ /a;  o';  a";  a"']rj  |  j  E  s(h)}  < 
[kh/a]kh 

Then  TRANS-SUB  with  (5.15)  gives 

for  h  E  1 ...  n  we  have  A{[¥j/W]rj  \  j  E  «(h)}  <  [kh/^]kh. 
By  repeated  use  of  and-elim-l-sub  and  and-elim-r-sub,  this  implies 

for  h  E  1  ...n  we  have  [Fi/3]ri  A  ...  A  [rm/!f]rm  <  [A:fc/s]fch, 
and  by  repeated  use  of  and-INTRO-SUB,  this  implies 


268 


CHAPTERS.  POLYMORPHIC  REFINEMENT  TYPE  CONSTRUCTORS 


Finally,  wc  can  use  rcon-sub  to  infer 

((Ii /a]kt  A  ...  A  (In/a]fe„)-*r  <  ([ri/ajr,  A  ...  A  [Fm/a]rh)-*r 

and  then  WEAKEN-TYPE  with  this  and  (5.14)  gives  our  conclusion.  □ 

Now  we  can  give  the  case  case  of  Theorem  2.101  (Infer  Returns  Principal  Type)  on 
page  151.  We  will  restate  the  theorem  first. 

Theorem  532  (Infer  Returns  Principal  Type)  If 

all  splits  of  types  in  VR  are  useless 


and 

and 

then 


infer  VR  e  terminates 
VRhe:r 
(infer  VR  e)  X  r 


Proof:  By  induction  on  e.  As  in  Chapter  2  on  page  152,  we  will  use 

For  all  r, 

( VR  H-  e  :  r  implies 

(infer  VR  e)  X  r) 
implies 
For  all  r, 

(VR  he:r  implies 

(infer  VR  e)  ■<  r) 


(5.16) 


Case:  e  oc  case  e0  of  q  =>  e]  |  ...  |  c„  =>  en  end:i 
such  that 


VRH-e  :  r. 

The  last  inference  of  this  must  be  CASE- TYPE  with  the  premises 


Suppose  we  have  an  r 


(5.17) 


VR  t"  eo  :  (ki)kc\  A  ...  A  ( kz)kcz , 


r  C  t, 

for  all  h  6  1 . . .  n  and  all  k\ , . . . ,  km,  whenever 

def  — - 

for  all  q  G  1 ...  z  we  have  c*  :  kq  <— » (a)kcq 
we  have 

VR  P  eh  :  ([I,/a|*i  A  ...'A  [Iz/S]fcz)  -*r, 
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and 


rtom(VR)  I -  e  ::t. 

Since  infer  VR  e  terminates,  infer  VR  eo  must  terminate.  By  induction  hypothesis. 


infer  VR  eo  <  ( k\)kc\  A  ...  A  ( kz)kct . 

Suppose  infer  VR  eo  has  the  form  (f\  )rcj  A ...  A  (Fm)rcm.  We  will  show  that  for  all  h 
and  all  (ri , . . . ,  rn)  in  seq  h,  we  have 

ifn  (infer  VR  eh,  [F  A  . . .  A  (Fm/5]rfc)  <  r. 

Then  trivial  properties  of  join  will  give  infer  VR  e  <  r,  which  is  our  conclusion. 

First,  choose  any  h  in  1 . . .  n  and  (rj, . . . ,  rm )  in  seq  h.  By  the  definition  of  seq,  this 
implies 

for  j  €  1 ...  m  we  have  ch  d?f  rj  <— >  (dt)rcj. 

Lemma  5.31  (Case  Statement  Body)  on  page  265  then  gives 

VR  h  eh  :  ([Fi/Sjr,  A  ...  A  [Fm/S])rn -> r. 

Since  infer  VR  e  terminates,  inf  er  VR  ej,  must  also  terminate.  Our  induction  hypoth¬ 
esis  then  gives 

infer  VR  eh  <  [F  i  /5]r,  A  ...  A  [rm/a]rm  r. 

Hence,  by  Fact  5.12  (Bound  on  Argument  to  i  Gives  Bound  on  i)  on  page  250  we  have 

ifn  (infer  VR  eh,  [F,/a]r!  A  ...  A  (Fm/a]rm)  <  r. 

Since  this  holds  for  all  h  and  all  (ri,...,rTO)  in  seq  h,  soundness  of  sjoinf  gives 
infer  VR  e  <r.  Summarizing  (5.17)  to  here, 

VRH-  e  :  r  implies  infer  VR  e  ■<  r 

By  (5.16),  this  implies  our  conclusion. 


Case:  Otherwise. 


Omitted. 


□ 


5.8  Declaring  Polymorphic  Type  Constructors 

Three  new  issues  arise  when  analyzing  rectype  declarations  with  polymorphic  type  con¬ 
structors:  we  must  determine  which  type  arguments  are  mixed,  positive,  negative,  and 
ignored;  we  must  ensure  that  Assumption  5.29  (Predefined  Intersection  Distributivity)  on 
page  259  holds;  and  we  must  construct  default  refinement  types  that  expressions  written 
without  concern  for  refinement  types  can  inhabit. 

Except  for  these  issues,  analyzing  rectype  declarations  with  type  variables  is  very 
similar  to  analyzing  the  same  declarations  with  all  the  variables  replaced  by  constants,  so 
the  theory  from  Chapter  3  applies  directly. 
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5.8.1  Separating  Mixed,  Positive,  Negative,  and  Ignored 

We  can  use  a  straightforward  abstract  interpretation  of  the  type  declaration  to  distinguish 
the  different  kinds  of  arguments  to  type  constructors.  We  separately  infer  whether  a  type 
variable  appearing  as  an  argument  occurs  positively  and  whether  it  occurs  negatively  in  the 
definition  of  the  type;  if  neither  is  true,  the  argument  is  ignored,  and  if  both  are  true,  the 
argument  is  mixed.  For  example,  given  the  datatypeq 

datatype  (a,/?)  mix  =  Mix  of  a— >(a*0) 

we  immediately  determine  that  a  is  mixed  and  (3  is  positive.  When  several  mutually 
recursive  type  constructors  are  declared  simultaneously,  we  may  have  to  iterate  to  determine 
the  best  classification.  For  example,  given  the  declaration 

datatype  (a,0)  ml  = 

A  of  (a,/3)  m2  I  B  of  a  *  a 
and  (7, 6)  m2  = 

C  of  (7,  S)  ml  |  D  of  8  — *  8 

we  will  have  to  use  at  least  two  iterations  to  determine  that  a  and  7  are  positive  and  0  and 
8  are  mixed.  Implementing  this  is  straightforward. 


5.8.2  Enforcing  Predefined  Intersection  Distributivity 

The  best  way  to  enforce  Assumption  5.29  (Predefined  Intersection  Distributivity)  on 
page  259  is  unclear.  The  following  theory  says  it  is  possible  to  effectively  discover 
declarations  for  which  this  assumption  is  not  true;  we  could  simply  reject  them,  but  it 
would  be  better  to  silently  repair  declarations  to  cause  the  rule  to  be  true.  It  is  not  obvious 
how  to  repair  the  declarations. 

The  following  fact  has  an  immediate  corollary  which  leads  to  an  algorithm  that  rec¬ 
ognizes  declarations  for  which  the  assumption  is  not  true.  The  main  idea  is  that  we  can 
determine  whether  the  assumption  is  true  for  all  vectors  of  refinement  types  we  could  sub¬ 
stitute  by  checking  it  in  one  special  case.  The  special  case  uses  a  vector  tc  of  monomorphic 
ML  type  constructors  and  two  vectors  o  and  b  of  monomorphic  refinement  type  construc¬ 
tors,  where  all  three  vectors  have  the  same  length  and  the  type  constructors  in  all  three  of 
these  vectors  are  distinct  from  each  other  and  from  any  other  type  constructors  mentioned 
in  the  lemma,  and  for  all  i  G  1 . . .  length(fc),  the  only  refinements  of  tc{i}  are  a{z},  6{i}, 

and  a{i}  A  b{i}.  Similarly,  we  use  the  vectors  a,  o',  and  a"  where  all  three  vectors  have 
the  same  length  as  tc  and  no  type  variable  appears  more  than  once  in  all  three  vectors. 
Then  we  have: 
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Fact  5.33  (Predefined  Intersection  Distributivity  Technical)  Suppose  a  and  b  are  as  de¬ 
scribed  above,  and  that  k  and  k'  are  vectors  of  refinement  types  where  k  A  k  refines  some 
t.  Let 

3  =  (o/a,  b/ct,{a  A  l)/**"] 

and 

s'  =  [k /a,  k'/ct,(k  Alt'), /a"]. 

Then,  for  any  refinement  types  k  and  k'  in  which  none  of  the  a{t'}’s  or  6{t}'s  appear,  if 

3(4)  <  3(4') 

then 

s'(k)  <  s'(k'). 


The  proof  of  this  is  a  straightforward  induction  on  the  derivation  of  3(4)  <  3(4').  Then  we 
have  the  following  corollary: 


Corollary  5.34  (Predefined  Intersection  Distributivity  Decidable)  Suppose  a  and  b  are 
as  described  above,  and  that  4  and  k'  are  vectors  of  refinement  types  where  4  A  4  refines 
some  t.  Then,  for  any  refinement  types  4  and  4'  in  which  none  of  the  a{t}’r  or  b{i}’s  appear, 

if 

[a/a]r  A  [6/a]r'  <  [a  A  6/a](r  A  r') 

then 

[4  /a ]r  A  [4,/a]r'  <  [4  A  k' / a](r  A  r'). 

Proof:  Use  the  previous  fact,  with  4  =  r  A  [a'/a]r' and  4' =  [a"/a](r  A  r').  □ 

At  this  point,  an  admittedly  slow  algorithm  for  checking  the  assumption  is  clear:  each 
time  we  analyze  a  rectype  declaration,  for  each  constructor  c  where 

cl?  t «-»  (at;  a2;  a3;  oU)tc, 

temporarily  introduce  new  tc ,  a,  and  b  as  described  in  the  corollary  above.  Enumerate  all 
r,  r',  re,  and  re'  such  that  c d?  r  »  (5)re  and  c  *f  r'  <-*  (a)re';  in  each  case,  verify  that 
[a/a2]r  A  [i/aijr'  <  (a  A  6/02]. 

There  may  be  faster  algorithms  for  doing  this  test,  and  there  may  be  ways  to  repair 
rectypa  declarations  that  fail  this  test  without  violating  the  intuitive  expectations  of  the 
programmer.  All  this  is  future  work. 
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5.8.3  Default  Refinement  Types 

As  the  example  in  Subsection  2.7.2  on  page  74  shows,  if  any  ML  type  has  more  than  one 
refinement,  there  will  be  programs  with  an  ML  type  that  have  no  refinement  type.  Once 
we  permit  mixed  type  arguments,  we  get  into  an  even  stranger  situation:  there  will  be  ML 
types  with  no  maximal  refinement.  For  example,  assuming  the  usual  refinements  of  the 
booleans  and  the  declared  ML  type  m  on  page  pagerefexample:mixed,  the  refinements  of 
bool  m  are  tt  Tra,  ff  Tm,  Tm,  T ^  Tm,  and  intersections  of  these.  There  is  no 
refinement  of  bool  m  that  is  greater  than  both  Tm  and  tt  T m. 

Since  there  is  no  refinement  type  that  includes  the  others,  the  terminology  “catch¬ 
all  type”  that  we  used  in  previous  chapters  is  not  appropriate.  Instead,  the  purpose  of 
the  default  type  is  to  provide  a  refinement  type  that  terms  with  an  ML  type  can  inhabit 
whenever  the  strangeness  from  Subsection  2.7.2  does  not  happen.  With  this  understanding, 
constructing  the  default  type  of  a  given  ML  datatype  is  still  straightforward:  define  the 
default  refinement  type  to  be  any  constructor  that  constructs  the  ML  datatype,  applied  to 
the  default  type  refining  the  argument  ML  type  of  the  constructor.  For  example,  given  the 
datatype 


datatype  (; ;  a; )  mix  =  Mix  of  a  — *(a  *  bool) 
the  default  refinement  type  is  defined  as 


rectype  (;;a;)  T.m«  =  Mix  (a  — ►(<*  *  T^j)) 


Chapter  6 

Declaring  Refinement  Types  for 
Expressions 


In  this  chapter  we  add  explicit  refinement  type  declarations  to  the  language  of  expressions; 
for  example,  the  expression 

fn  x:bool  =>  (x[]  <  tt) 

will  have  the  type  tt  — *•  tt  but  not  the  type  ff  -*ff.  Adding  this  feature  is  surprisingly 
simple. 

The  <1  operator  is  coercive,  in  the  sense  that  the  best  refinement  type  of  a  expression' 
of  the  form  e  <3  r  will  be  r,  if  it  has  any  type  at  all.  We  can  also  imagine  a  non-coercive 
version,  which  we  shall  call  <d'.  The  best  type  of  e  <3'  r  would  be  the  best  type  of  e,  if  that 
type  is  less  than  r;  otherwise  the  expression  has  no  type. 

Both  operators  are  simple,  but  <1  is  more  elegant  because  we  can  use  <1  to  implement 

but  not  vice  versa.  To  use  <3  to  implement  <3',  regard  the  expression  e  <3'  r  as  an 
abbreviation  for  (fn  z :t  =>  ((fn  x:t  =>  fn  y:f  =>  x[])  z[]  (z[]  <1  r)))  e,  where  t  is 
a  valid  ML  type  for  e. 

Type  inference  for  <  is  simple.  First  we  add  the  syntax  to  the  language;  we  will  still 
have  a  use  for  expressions  without  any  <3  operators,  so  we  will  keep  the  metavariable  e  with 
the  meaning  it  was  given  on  page  242  and  use  the  metavariable  d  to  stand  for  expressions 
that  may  have  <3  operators.  Thus  the  grammar  for  d  is: 

d  d  <3  r  j 

z[f]  |  fn  x:t  =>  d\d  d  |  c[f]  d  \ 

case  d  of  c  =>  d  |  ...  |  c  =>  d  end :t  | 

(d,  ...»  d)  |  ()  |  elt_m_n  d  | 
fix  f:t  =>  fn  x:t  =>  d  \ 
let  x  =  A(a).d  in  d  end 


273 


274  CHAPTER  6.  DECLARING  REFINEMENT  TYPES  FOR  EXPRESSIONS 


Our  language  of  types  is  unchanged,  so  results  such  as  Fact  5.21  (Finite  Refinements)  on 
page  252  continue  to  hold.  Type  inference  for  expressions  with  refinement  type  declarations 
is  the  same  as  type  inference  for  expressions  without  refinement  type  declarations,  except 
we  add  this  rule: 

VR  f-  d  :  r 

DECL-TYPE:  — 

VR  r  (a  <  r) :  r 

Strictly  speaking,  we  also  need  to  take  the  rules  in  effect  for  e  (see  page  254)  and  assert  that 
they  still  hold,  except  all  e’s  in  those  rules  should  be  changed  to  d’s. 

Instead  of  using  coercive  declarations  to  implement  non-coercive  declarations,  we  could 
treat  non-coercive  declarations  directly  by  adding  this  rule: 

,  VR  V-  d.T  t  <  k 
DECL-TYPE’: 

The  presence  or  absence  of  this  rule  has  little  impact  on  the  reasoning  below. 

With  these  declarations  there  comes  a  new  phenomenon:  expressions  can  now  have  free 
refinement  type  variables.  Attempts  to  directly  define  a  notion  of  evaluation  on  expressions 
with  declarations  lead  to  pointless  questions  about  how  to  instantiate  free  refinement  type 
variables  while  evaluating  let  statements.  To  avoid  these  questions,  we  simply  erase  the 
refinement  type  declarations  before  evaluating: 

Definition  6.1  (Erase)  We  use  the  notation  erase (4)  to  mean  d  with  all  of  the  refinement 
type  declarations  erased. 

Our  soundness  result  therefore  reads  as  follows: 

Theorem  6.2  (Refinement  Type  Soundness)  //erase(d)  =j>  v  and  d  :r,  then  •  H  v  :  r. 

Proof:  We  can  use  induction  to  prove  that  -  I -  d  .  r  implies  •  F  erase(<f)  :  r.  Thus 
•  F  erase(d) :  r,  and  we  can  apply  Theorem  4.7  (Refinement  Type  Soundness)  on  page  237 
to  get  our  conclusion.  □ 

The  algorithm  for  inferring  refinement  types  for  expressions  with  refinement  type  dec¬ 
larations  is  also  simple.  We  add  the  following  case: 

fun  infer  VR  d  <J  r  = 

if  rtom(VR)  F  erase(d)  ::  t  then 

let  t  =  the  unique  t  such  that  rtom(VR)  F  erase (4) ::  t 
in 

if  subtypep  (infer  VR  d)  r  t  then  r  else  ns 

end 

else  ns 


The  soundness  proof  for  this  is  straightforward  and  we  omit  it. 


Chapter  7 

Implementation 


An  implementation  of  refinement  type  inference  has  been  written  in  Standard  ML.  It 
corresponds  well  with  the  theory  developed  in  the  previous  chapters,  and  it  runs  reasonably 
quickly.  This  chapter  discusses  the  technical  issues  that  had  to  be  resolved  to  create 
this  implementation;  this  chapter  is  not  meant  to  be  complete  instructions  for  using  the 
implementation. 

Since  the  language  of  the  implementation  resembles  the  object  language,  there  is  poten¬ 
tial  for  confusion  between  the  object  and  the  implementation  languages.  Worse,  examining 
types  of  expressions  in  the  implementation  language  is  useful  when  trying  to  understand  the 
implementation,  so  we  must  add  yet  another  kind  of  type  to  the  discussion.  We  call  types 
in  the  implementation  language  “SML  types”,  to  distinguish  them  from  the  “ML  types”  in' 
the  object  language  described  in  the  previous  chapters. 

The  syntax  for  the  expressions  recognized  by  the  implementation  is  similar  to  the 
grammar  appearing  on  page  274,  except  we  implement  ML  type  inference  so  explicit  ML 
types  need  not  appear  in  terms.  The  grammar  does  not  closely  resemble  true  SML.  A 
simple  interaction  with  the  implementation  is  below.  In  the  example,  the  refinement  type 
declaration  operator  “<d”  is  written  as  “<:”  and  the  operator  ►”  is  written  as  Input 
typed  by  the  user  is  preceded  by  >-  or  >=. 
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>-  datatype  bool  ■  true  of  unit  I  false  of  unit 
>=  rectype  tt  =  true  (unit)  and  ff  =  false  (unit); 
>-  true; 

it :  (unit  ->  bool)  : : 

(unit  ->  tt) 

>-  true  <:  ff; 

Failed  to  unify  (unit  ->  bool)  and  bool 
while  ML  type  checking  true  <:  ff . 

ML  type  check  failed. 

>-  (true  ())  <:  ff; 
it :  bool  : : 

<:  invalid  for  term  (true[]  ()). 

It  actually  had  the  type: 
tt 

You  tried  to  coerce  it  to  the  type  ff . 

>-  (true  ())  <:  tt; 
it :  bool  : : 
tt 
>- 


As  is  the  case  in  the  theory  described  in  previous  chapters,  all  value  constructors  take 
exactly  one  argument.  Notice  that  at  no  point  do  we  calculate  a  value;  this  implementation 
of  refinement  type  inference  does  not  implement  any  kind  of  evaluation. 

The  implementation  has  many  boolean  flags  that  the  user  can  manipulate  to  turn  on  and 
off  various  performance  optimizations  in  the  type  checker.  The  flags  are  all  false  b>  default; 
the  flags  are  defined  in  such  a  way  that  the  default  is  usually  best.  A  given  flag  /  can  be 
set  with  the  top  level  command  “setflag  /;”  or  cleared  with  the  top  level  command 
“clearflag  /;”.  A  list  of  all  flags  with  a  description  and  the  present  value  of  each  is 
printed  whenever  the  flag  argument  to  setflag  or  clearflag  is  invalid. 

Most  of  the  optimizations  discussed  below  can  be  turned  off  by  setting  some  flag.  We 
justify  most  optimizations  to  type  inference  by  citing  how  turning  off  the  optimization 
makes  some  example  run  more  slowly.  All  run  times  in  this  chapter  were  measured  on  a 
SPARCstation  iPX. 


7.1  Representations 


This  section  discusses  how  the  various  mathematical  objects  discussed  in  previous  chapters 
are  represented  in  the  implementation. 
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7.1.1  Type  Constructors 

The  Definition  of  Standard  ML  [MTH90]  makes  a  distinction  between  a  type  name  and  a 
type  identifier.  Type  identifiers  are  simply  the  strings  appearing  in  the  program  text  that 
refer  to  various  types;  for  example,  if  we  have  a  declaration  of  the  form  type  t  =  . . . 
that  is  shadowed  by  a  later  declaration  of  the  form  datatype  t  =  ....  both  of  the  types 
have  the  same  identifier  t.  In  contrast,  type  names  are  unique  for  each  type;  since  the  two 
types  with  identifier  t  are  different,  they  will  have  different  type  names. 

In  the  implementation  refinement  types  we  make  even  more  distinctions.  First  we  have 
refinement  type  identifiers  (ref  conid’s)  and  ML  type  identifiers  (mlconid’s),  which  are 
both  implemented  as  strings.  Then  we  have  refinement  type  names  (ref  conname’s)  and 
ML  type  names  (mlconname’s),  which  are  unique  identifiers.  These  are  equality  types, 
so  they  can  easily  be  used  as  keys  for  tables.  Finally,  we  have  ML  type  constructors 
(mlconstructor’s),  which  have  an  mlconname  and  other  information  describing  all  the 
refinements  of  that  ML  type  name. 

Refinement  type  identifiers  and  names  are  represented  as  follows: 
type  refconid  =  string 

type  refconname  =  {refconid  :  refconid,  uniqueid  :  int,  index  :  int} 

The  uniqueid  field  of  ref  conname’s  is  used  to  distinguish  different  refinement  type 
constructors  with  the  same  name.  If  an  ML  type  constructor  tc  is  refined  by  the  refinement 
type  constructors  rc\ , . . . ,  nc„,  then  the  index  field  of  the  representations  of  these  refinement 
type  constructors  will  be  distinct  integers  in  the  range  0, . . .  ,n  -  1,  in  some  order.  This 
allows  us  to  implement  functions  mapping  a  refinement  of  tc  to  some  other  value  as  a 
simple  array  reference. 

ML  type  identifiers  and  names  are  represented  as  follows: 

type  mlconid  =  string 

type  low.mlconname  =  mlconid  *  int 

datatype  mlconname  = 

Tuple  of  int 
I  Arrow 

I  Custom  of  low  .mlconname 

This  is  all  very  straightforward:  Tuple  n  stands  for  ttuplen,  Arrow  stands  for  tarrow, 
and  Custom  (s ,  i)  stands  for  the  user-defined  ML  type  constructor  with  the  name  s.  The 
integer  t  has  the  same  role  as  the  uniqueid  field  of  refinement  type  constructor  names. 

Note  that  mlconname’s  distinguish  separate  cases  for  arrow  and  tuple  types,  but 
ref  conname’s  do  not.  This  does  not  create  ambiguity  because  whenever  the  implemen¬ 
tation  uses  a  refinement  type  constructor,  it  always  has  on  hand  the  ML  type  constructor 
that  this  refinement  type  constructor  refines.  Thus  if  a  refinement  type  constructor  refines 
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an  ML  type  constructor  with  the  name  Arrow,  it  must  be  the  representation  of  rarrow.  In 
this  case  we  put  arbitrary  values  in  the  ref  conid,  unique  id,  and  index  fields.  We  do  the 
same  for  tuple  refinement  type  constructors. 

The  ML  type  constructor  itself  is  a  record  containing  the  ML  type  constructor  name, 
along  with  other  information  describing  its  refinements.  The  meanings  of  the  fields  are 
discussed  below. 

datatype  mlconstructor  = 

HLConstr  of 
{name  :  mlconname, 

unique_ref inements  :  refconname  list, 

nonunique.ref inements  :  (refconname,  refconname)  S . substitution, 
bottom  :  refconname, 
bottom. emptyp  :  bool, 
top  :  refconname, 

tor  :  (refconname  *  refconname)  ->  refconname, 
tand  :  (refconname  *  refconname)  ->  refconname, 
tleq  :  (refconname  *  refconname)  ->  bool, 
negargpos  :  int  list, 
posargpos  :  int  list} 

The  unique.ref inements  and  nonunique.ref  inements  fields  are  used  to  keep  redun¬ 
dant  refinements  of  an  ML  type  from  slowing  refinement  type  inference.  For  example,  if 
this  declaration  is  given  to  refinement  type  inference: 

datatype  bool  -  true  of  tunit  I  false  of  tunit 
rectype  tt  =  true  (tunit) 
and  ff  3  false  (tunit) 
and  A-hoi  =  bottom  bool; 


then  the  refinement  types  tt  A  ff  and  J-booi  will  be  equivalent.  The  unique.ref  inements 

def 

field  has  a  list  of  the  refinements  we  will  use  (which  excludes  tt  A  ff),  and 
nonunique.ref  inements  has  a  substitution  mapping  each  refinement  we  will  not  use 

def 

into  the  corresponding  one  we  will  use  (in  this  case,  tt  A  ff  is  mapped  to  ±booi)- 

Skipping  forward,  the  tor,  tand,  and  tleq  fields  contain  functions  that  can  join, 
intersect,  and  compare  the  refinements  of  this  ML  type  constructor.  The  functions  tor  and 
tand  only  have  elements  of  unique.ref  inements  as  their  range,  to  make  it  possible  to 
pay  as  little  attention  as  possible  to  the  redundant  refinement  type  constructors. 

The  fields  bottom  and  top  have  the  least  and  greatest  refinement  of  this  ML  type 
constructor,  respectively.  These  fields  are  redundant;  we  could  compute  them  by  us¬ 
ing  the  functions  stored  in  the  tand  and  tor  fields  to  combine  the  types  listed  in 
nonunique.ref  inement  s. 
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The  bottom. eraptyp  field  is  used  to  evaluate  the  h  r  empty  judgement  described  in 
Chapter  3.  If  this  flag  is  true,  we  assume  that  the  refinement  in  the  bottom  field  is  empty, 
otherwise  we  assume  it  is  not.  We  assume  that  all  nonredundant  refinements  other  than 
the  one  in  the  bottom  field  are  not  empty,  since  otherwise  they  would  be  equivalent  to  the 
refinement  in  the  bottom  field,  and  therefore  they  would  be  redundant. 

All  type  arguments  in  the  implementation  are  either  positive  or  negative.  Mixed 
arguments  are  outlawed  and  ignored  arguments  are  treated  as  positive.  Syntactically,  each 
ML  type  constructor  has  one  linear  list  of  arguments,  as  they  do  in  SML;  but  internally, 
we  treat  the  negative  type  arguments  very  differently  from  the  positive  ones,  so  we  keep 
them  segregated  into  separate  lists.  The  posargpos  and  negargpos  fields  say  how  to  do 
the  segregation.  If  we  sequendally  assign  numbers  (starting  with  zero)  to  the  syntactic 
type  arguments,  then  posargpos  is  a  list  of  the  numbers  for  positive  type  arguments  and 
negargpos  is  a  list  of  the  numbers  for  negative  type  arguments.  For  example,  given  the 
declaration 


datatype  (a,/3,7)  d  -  D  of  /3  *(<*—►  7) 

argument  number  0  (a)  is  negative  and  arguments  1  (/3)  and  2  (7)  are  positive,  so  the 
negargpos  field  of  d  will  be  [0]  and  the  posargpos  field  will  be  [1 ,  2] . 


7.1.2  ML  types  and  type  schemes 

We  represent  ML  types  with  the  datatype 

datatype  mlty  = 
MLCon  of  {neg 
pos 


mlty  list, 
mlty  list. 


con  :  mlconstructor} 
MLTvvar  of  V.tvvar 


where  V.tyvar  is  a  representation  of  type  variables.  This  is  a  direct  encoding  of  the 
grammar  for  ML  types  given  on  page  242,  except  we  have  already  segregated  the  negative 
and  positive  type  arguments;  from  the  negargpos  and  posargpos  fields  of  the  constructor, 
it  is  obvious  how  to  merge  the  neg  and  pos  fields  to  get  the  type  arguments  in  the  order  the 
user  expects. 

The  encoding  of  ML  type  schemes  is  straightforward  as  well: 

datatype  mlscheme  = 

MLScheme  of  (V.tyvar  list  *  mlty) 

These  encodings  of  ML  types  are  straightforward  enough  that  we  will  ignore  them  in 
this  chapter,  and  use  the  same  notation  for  ML  types  in  this  chapter  that  we  have  used  in 
previous  chapters. 
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7.1.3  Refinement  Types 

The  implementation  has  different  representations  for  the  refinement  types  appearing  in 
explicit  declarations  (such  as  it  in  (true  ())  <1  it)  and  refinement  types  that  are  inferred 
for  an  expression  by  the  implementation.  After  we  describe  both  representations,  we  will 
explain  below  how  the  special  representation  for  refinement  types  in  explicit  declarations 
allows  quick  checking  of  the  assertions  in  expressions  containing  <3 . 

The  representation  for  refinement  types  appearing  in  explicit  declarations  is  simple,  and 
similar  to  the  representation  of  ML  types: 

datatype  syntp  = 

SAnd  of  syntp  list 
I  SCon  of  {pos  :  syntp  list, 

neg  :  syntp  list,  ref con  :  refconname} 

I  SVar 

Since  we  usually  know  which  ML  type  a  refinement  type  refines,  we  only  have  one 
representation  SVar  for  all  type  variables  appearing  in  explicitly-declared  refinement  types. 

We  represent  inferred  refinement  types  with  a  function  that  computes  the  interpretation 
i  of  the  refinement  type  as  in  Definition  5.8  on  page  248,  along  with  a  few  other  fields  that 
make  some  optimizations  possible.  The  representation  of  refinement  types  is: 

datatype  tp  * 

Ref  Con  of  (teqopt  *  bool  *  mlconstructor  * 

(tp  list  ->  (tp  list  *  refconname))) 

I  Reftyvar 

Ref tyvar  is  analogous  to  SVar;  it  stands  for  a  type  variable,  but  it  does  not  bother  to  say 
which  one,  because  there  is  generally  an  ML  type  on  hand  that  makes  that  clear.  If  the 
refinement  type  is  not  a  type  variable,  then  the  constructor  is  Ref  Con  with  a  tuple  of  four 
components  as  its  argument. 

Skipping  ahead,  the  fourth  component  of  the  tuple  is  the  interpretation,  represented  as  a 
function  in  the  obvious  way.  We  only  have  one  argument  to  the  function  because  we  outlaw 
mixed  type  variables. 

The  first  component  of  the  tuple  has  the  type  teqopt  which  we  have  not  yet  dis¬ 
cussed.  This  type  is  used  for  memoizing  refinement  type  equality,  and  it  is  discussed  with 
memoization  in  Subsection  7.2.4  below.  In  practice,  the  implementation  uses  a  utility  pro¬ 
cedure  called  eRef  Con  that  inserts  the  teqopt;  eRef  Con  takes  as  argument  a  tuple  with  the 
last  three  components  of  the  argument  to  Ref  Con,  it  constructs  and  inserts  an  appropriate 
teqopt,  and  it  calls  Ref  Con  and  returns  the  resulting  tp. 

The  implementation  of  refinement  types  uses  references  when  it  finds  a  type  for  a  fixed 
point.  As  the  values  stored  in  these  references  change,  the  behavior  of  the  functional 
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component  of  some  refinement  types  can  change;  we  say  these  refinement  types  are  not 
constant.  It  is  important  not  to  memoize  these  refinement  types,  because  the  information 
stored  in  the  memo  table  may  not  be  accurate  by  the  time  it  is  used.  To  ensure  this,  we  use  the 
second  component  of  the  uple  in  each  refinement  type  created  by  Ref  Con  to  record  whether 
the  refinement  type  is  constant.  For  a  more  complete  discussion,  see  Subsection  7.2.2. 

The  third  component  of  the  tuple  is  the  ML  type  constructor.  This  is  redundant  and 
could  be  eliminated;  it  is  presently  used  so  we  can  recognize  arrow  and  tuple  types  when 
printing  refinement  types  during  debugging,  and  so  we  can  form  intersections  and  joins  of 
refinement  types  without  having  to  pass  around  the  ML  type  that  they  refine. 

Given  the  functional  component  of  a  tp  and  a  syntp,  one  can  efficiently  determine 
whether  the  tp  is  a  subtype  of  the  syntp.  If  the  syntp  is  an  intersection,  then  the  tp 
is  a  subtype  of  the  syntp  if  and  only  if  it  is  a  subtype  of  all  of  the  components  of  the 
intersection.  If  the  syntp  is  SVar,  then  ML  type  inference  should  have  ensured  that  the 
tp  is  Ref  tyvar,  so  the  tp  is  a  subtype  of  the  syntp.  Lastly,  if  the  syntp  is  a  SCon,  then 
we  use  the  definition  of  i  to  convert  the  negative  arguments  of  the  syntp  into  a  tp,  we 
pass  those  negative  arguments  to  the  functional  component  of  the  tp,  and  we  recursively 
compare  the  result  of  the  function  call  to  the  positive  arguments  of  the  syntp. 


7.2  Refinement  Type  Inference 

Refinement  type  inference  is  similar  to  the  type  inference  algorithm  described  at  the  ends 
of  Chapters  2,  4,  and  5.  The  main  change  is  the  lazy  representation  of  refinement  types; 
this  immediately  leads  to  the  needs  for  memoization,  pending  analysis  for  fixed  points, 
and  an  interesting  instantiation  algorithm.  Lazy  representations  of  types  also  appear  in 
[HM94].  Once  these  issues  are  understood,  there  is  little  to  be  gained  by  writing  out  the 
entire  algorithm;  instead,  we  will  only  deal  with  interesting  cases  of  it  below. 


7.2.1  Laziness 

Often  a  function  will  only  be  used  at  a  few  of  the  types  for  which  it  is  defined.  This 
tendency  is  especially  strong  for  higher-order  functions,  since  functional  ML  types  can 
have  so  many  distinct  refinements.  For  example,  assuming  the  usual  rectype  declaration 
for  the  booleans  is  in  effect,  the  refinement  type  given  to  double  by  the  declaration 

val  double  =  fn  f  =>  fn  x  =>  f  (f  ( x:bool )); 


is  an  intersection  of  1 12  components.  By  representing  refinement  types  as  functions  that 
can  compute  the  relevant  components  of  the  intersection  on  demand,  we  can  usually  avoid 
computing  all  1 12  components  and  storing  them  in  memory. 
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The  case  of  type  inference  that  reflects  this  principle  most  clearly  deals  with  abstractions. 
Using  the  notation  in  the  original  definition  of  the  type  inference  algorithm  in  Figure  2.7 
on  page  142,  this  is  the  modified  algorithm: 


I  infer  VR  (fn  x:t  ->  e')  * 

if  there  is  a  it  such  that  rtom(VR)[®  :=  i]  I-  e' ::  tt 

then 

let  val  tt  *  the  unique  it  such  that  rtom(VR)[x  :=  t]  h  e' ::  it 
fun  do_one  r  = 

sjoinf  it  {infer  (VR[se  :=  r'])  e'  |  r'  6  split  r} 
in 

Ref  Con  (. ..,  ...»  tarrow,  fn  [x]  =>  ([do.one  x]  ,  narrow)) 
end 
else  ns 


where  we  have  omitted  the  first  two  components  of  the  argument  of  Ref  Con.  In  the  actual 
implementation,  the  ML  type  it  of  the  entire  abstraction  is  stored  in  the  abstract  syntax  of 
the  abstraction,  so  refinement  type  inference  does  not  have  to  invoke  ML  type  inference. 


7.2.2  Fixed  Points 


The  method  for  finding  least  fixed  points  in  the  fix  case  of  the  algorithm  in  Figures  2.7 
and  2.8  on  pages  142  and  143  is  an  instance  of  a  general  technique:  start  with  the  least 
possible  value,  and  repeatedly  apply  the  function  we  want  the  fixed  point  of  until  the  result 
stops  changing.  This  technique  does  not  work  well  with  lazy  representations  of  refinement 
types  because  comparing  the  results  of  one  iteration  to  the  results  of  the  next  causes  us  to 
evaluate  both  results  completely. 

Instead,  we  use  a  technique  called  pending  analysis.  This  technique  allows  one  to 
evaluate  the  abstract  interpretation  of  a  fixed  point  at  any  given  point;  this  evaluation 
examines  a  minimal  number  of  other  points.  It  is  easiest  to  explain  this  with  an  example; 
for  a  more  formal  description,  see  any  of  [Jag89,  Dix88,  You89].  The  tables  of  pending 
values  resemble  the  minimal  function  graphs  of  [JM86]. 

Suppose  we  have  the  declarations 
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datatype  a  list  ■  cons  of  a  *  a  list  \  nil  of  tunit 
rectype  a  tv  *  nil  (tunit)  I  cons  (a  *  a  od) 
and  a  od  *  cons  (a  *  a  e«) 
and  a  cm  =  nil  (<uni<) 
and  a  nem  s  cons  (a  *  a  Tk#<) 
and  a  ±u*t  ~  bottom  (a  list); 
datatype  bool  =  true  of  tumi  I  false  of  lunti 
rectype  =  true  (tunit) 
and  ff  =  false  (tunit) 
and  =  bottom  &oo/; 

and  (using  the  concise  syntax)  the  function  definitions 

fun  not  (true  ())  *  false  () 

I  not  (false  ())  *  true  () 

fun  boolmap  (f  :bool  ->  bool)  ((nil  ()):bool  list)  =  nil  () 

1  boolmap  f  (cons  (hd,  tl))  =  cons  (f  hd,  boolmap  f  tl) 

or,  in  the  formal  syntax,  the  function  definitions 

val  not  =  f n  x :  bool  => 

case  x  of  true  =>  false  |  false  =>  true  end: bool; 
val  boolmap  « 

fix  boolmap :  (bool  — *•  bool)  — >  bool  list  —*  bool  list  -> 
fn  f :  bool  —*  bool  =>  fn  1 :  bool  list  => 
case  1  of 

nil  =>  fn  tunit  ->  nil  () 

I  cons  =>  f  n  p :  bool  *  bool  list  => 

cons  (f  (elt_l_2  p),  boolmap  f  (elt_2_2  p)) 
end:  bool  list; 

and  suppose  we  want  to  find  the  principal  type  for 

boolmap  not  (cons  (true  (),  nil  ())). 

We  start  with  an  abstract  interpretation  using  a  strategy  very  similar  to  the  strategy  for 
actually  evaluating  the  expression.  This  becomes  interesting  when  we  must  t?ke  steps  to 
ensure  that  abstract  interpretation  terminates  even  in  the  presence  of  recursion.  The  type  of 
boolmap  has  the  form 

Ref Con  (teqoptl,  true,  tarrow,  boolmapfn’), 

where  t arrow  is  an  ML  constructor  representing  arrow  types  and  boolmapfn'  is  some 
function.  Similarly,  the  type  of  not  is  some  unimportant  structure  wrapped  around  a  function 
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we  shall  call  notfn’.  From  the  declaration  of  Ref  Con  on  page  280,  we  know  that  both 
boolmapfn’  and  notfn’  have  the  SML  type  tp  list  ->  (tp  list  *  refconname). 
Because  the  ML  type  constructor  named  Arrow  has  one  negative  argument,  the  list  of  tp’s 
passed  to  boolmapfn’  and  notfn’  will  always  have  exactly  one  element.  Because  Arrow 
has  one  positive  argument,  the  list  of  tp’s  returned  from  boolmapfn'  and  notfn’  will 
also  always  have  exactly  one  element.  Since  Arrow  is  refined  by  only  one  refinement  type 
constructor,  the  refconname  returned  from  both  boolmapfn  and  notfn  will  always  be 
that  refinement  type  constructor.  Thus  we  can  represent  all  the  information  in  boolmapfn’ 
and  notfn’  using  functions  with  the  SML  type  tp  ->  tp;  we  will  call  these  functions 
boolmapfn  and  notfn. 

The  interior  structure  of  the  type  of  cons  (true  (),  nil  ())  is  not  relevant  for  this 
example,  so  we  will  write  that  type  as  a  mathematical  refinement  type:  tt  od. 

We  take  the  behavior  of  notfn  as  given,  and  our  goal  in  this  example  is  to  describe  the 
behavior  of  boolmapfn  when  it  is  passed  the  arguments  notfn  and  tt  od. 

If  we  had  no  concerns  about  termination  of  type  inference,  we  could  simply  make 
the  abstract  interpretation  of  boolmap  recur  at  the  same  point  in  the  code  where  boolmap 
itself  recurs.  We  would  start  with  f  having  the  type  notfn  and  1  having  the  type  tt  od. 
(Throughout  this  scenario,  f  will  have  the  type  notfn,  so  we  will  not  mention  it  again.) 
We  can  summarize  this  situation  with  the  notation 

boolmapfn  notfn  (tt  od)  =  ? 

We  can  construct  an  odd  length  list  starting  with  either  an  empty  list  or  an  nonempty, 
even  length  list,  so  the  abstract  interpretation  would  make  two  recursive  calls  to  the  body 
of  boolmap:  one  where  1  has  the  type  tt  em  (this  returns  immediately  with  the  result 

del 

Lioo/  em)  and  one  where  1  has  the  type  tt  (ev  A  nem).  We  can  summarize  the  current 
situation  with  the  table 

boolmapfn  notfn  (tt  od)  =  ? 

boolmapfn  notfn  (tt  em)  =-Lj00/  em 

.  def 

boolmapfn  notfn  (tt  (ev  A  nem))  =  ? 

def 

Continuing,  the  call  with  argument  tt  (ev  A  nem)  gives  rise  to  a  recursive  call  where  1  has 
the  type  tt  od.  This  is  the  argument  we  started  with,  so  if  we  continue  in  the  fashion  we 
have  up  to  this  point,  we  will  have  an  infinite  loop. 

The  solution  to  this  problem  is  the  essence  of  pending  analysis.  Instead  of 
continuing  with  the  recursion,  we  behave  as  though  the  inner  recursive  call  to 
boolmapfn  notfn  (tt  od)  simply  returns  the  least  type  we  have  observed  so  far  for 
the  expression  boolmapfn  notfn  (tt  od).  Since  our  table  lists  “?”  as  the  entry  corre¬ 
sponding  to  boolmapfn  notfn  (tt  od),  we  have  not  yet  observed  any  types  returned  from 
this  expression,  so  we  return  the  least  available  type  for  the  expression,  which  is  ±u,t. 

def 

Under  this  assumption,  the  value  returned  when  1  is  tt  (ev  A  nem)  is  ff  ±u,t.  This  type  is 
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less  than  the  true  type  when  1  is  tt  (ev  A  nem);  we  will  revise  it  later.  This  table  describes 
the  current  situation: 

boolmapfn  notfn  (tt  od)  =  ? 

boolmapfn  notfn  (tt  em)  =-Lb*>i  em 

,  .  def  . . 

boolmapfn  notfn  (tt  (ev  A  nem))  =  ff  ±tut 

Now  we  can  finish  this  part  of  the  abstract  interpretation;  we  take  the  join  of  em  and 

ff  J -tut  and  apply  cons,  yielding  ff  od  and  the  following  table: 

boolmapfn  notfn  (tt  od)  =  ff  od 

boolmapfn  notfn  (tt  em)  =  _L \,00i  em 

boolmapfn  notfn  (tt  (ev  A  nem))  =  ff  J./.-.j 

Call  this  table  “Generation  1”.  Although  we  have  the  correct  answer  to  the  problem  we  are 
interested  in,  this  table  is  peculiar  because  the  solutions  to  the  subproblems  listed  on  the 
second  and  third  lines  are  too  small.  We  were  lucky  this  time;  in  general,  at  this  point  in 
the  computation,  the  proposed  solution  to  the  top-level  problem  can  be  too  small. 

This  happened  because  we  knew  too  tittle  when  we  computed  some  of  the  subproblems. 
A  natural  approach  is  to  repeat  the  computation,  but  whenever  a  subproblem  that  would 
otherwise  cause  a  loop  arises,  we  use  the  value  from  Generation  1  instead  of  the  least  type 
available.  Doing  this  results  in  the  correct  result  for  the  top-level  problem  again,  and  also 
a  correct  table: 

boolmapfn  notfn  (tt  od)  =  ff  od 

boolmapfn  notfn  (tt  em)  =  ff  em 

.  .  dcf  .  def 

boolmapfn  notfn  (tt  (ev  A  nem))  =  ff  (ev  A  nem) 

Call  this  “Generation  2”.  We  only  know  this  is  a  correct  table  because  we  have  foreknowl¬ 
edge  of  the  correct  result;  the  only  way  the  implementation  can  determine  that  this  table  is 
correct  is  by  using  it  to  calculate  a  third  generation,  and  seeing  that  Generations  2  and  3  are 
identical. 

It  is  plausible,  but  not  at  all  obvious,  that  this  procedure  gives  correct  results.  For 
proofs,  see  [Dix88]. 

The  implementation  organizes  the  table  representing  these  generations  as  an  association 
list.  Searching  the  association  list  can  be  expensive,  in  general,  because  comparing  types 
can  be  expensive.  Therefore  each  entry  in  the  table  is  a  reference  that  can  be  updated  in 
place;  this  avoids  the  usual  accumulation  of  useless  entries  in  an  association  list  as  new 
entries  are  added  to  the  beginning. 

Unfortunately,  this  also  means  that  some  refinement  types  have  functions  embedded 
in  them  that  make  non-trivial  use  of  references.  In  general,  if  a  subexpression  has  a  free 
variable  that  is  bound  by  a  surrounding  fix  operator,  its  type  will  contain  a  function  that 
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may  change  as  we  search  for  the  fixed  point.  Putting  this  type  in  a  memo  table  would  cause 
problems,  because  the  behavior  of  the  type  may  change  with  time.  To  ensure  that  these 
types  are  never  placed  in  a  memo  table,  each  refinement  type  other  than  Reftyvar  has  a 
boolean  field  that  is  set  to  true  if  it  definitely  uses  no  references  (that  is,  it  is  constant), 
and  false  if  it  may  use  nontrivial  references  of  this  kind.  This  is  the  second  component  of 
the  tuple  argument  to  Ref  Con  on  page  280. 


7.2.3  Optimizing  Equality 

The  ab  jve  technique  requires  us  to  look  up  types  in  a  table  and  to  determine  whether  one 
table  is  identical  to  another.  Both  of  these  problems  rely  heavily  on  determining  when  types 
are  equal  to  each  other.  There  are  several  steps  that  can  be  taken  to  make  this  efficient. 

The  straightforward  implementation  of  type  equality  (based  on  a  generalization  of  the 
subtypep  function  from  page  1 19  to  operate  on  refinement  type  constructors  with  negative 
type  arguments)  is  fairly  fast  for  types  without  any  negative  arguments  because  in  that  case 
allref  s  is  never  used  to  enumerate  the  refinements  of  an  ML  type.  However,  whenever 
we  compare  refinements  of  an  ML  type  with  non-trivial  negative  type  arguments  such  as 
( bool  — *•  bool)  — >  bool,  we  will  have  to  enumerate  all  of  the  refinements  of  the  negative  type 
arguments;  in  this  example,  we  have  exactly  one  negative  type  argument  bool  — *•  bool. 

To  have  as  few  of  these  expensive  enumerations  as  possible,  we  memoize  type  equality. 
Whenever  a  refinement  type  is  not  Ref  tyvar,  it  contains  a  tuple  where  the  first  component 
has  the  type  teqopt  which  is  used  for  this  purpose.  The  definition  of  teqopt  is: 

datatype  teqopt  =  TeqOpt  of  {sameas:  UF.set, 

diff erentfrom:  UF.set  list  ref} 

This  definition  is  a  datatype  with  only  one  constructor  rather  than  a  type  abbreviation 
because  SML  does  not  allow  type  abbreviations  in  signatures.  The  type  UF .  set  represents 
equivalence  classes;  UF  is  a  name  for  a  structure  with  this  signature: 

signature  UNIONFIND  = 
sig 

type  set 

val  newset  :  unit  ->  set 

val  union  :  set  ->  set  ->  unit 

val  sameset  :  set  ->  set  ->  bool 

end 

Think  of  a  set  here  as  a  name  for  something.  The  function  newset  creates  a  new  name, 
uniondeclares  that  two  names  really  stand  for  the  same  thing,  and  sameset  reports  whether 
all  of  the  union’s  done  so  far  imply  that  two  given  names  stand  for  the  same  thing.  As  the 
name  of  the  signature  implies,  this  is  the  classic  Union-Find  problem,  discussed  in  f  AHU74, 
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page  124].  The  names  set  and  union  are  part  of  the  standard  nomenclature  used  with  that 
problem.  The  implementations  of  these  operations  run  in  almost  constant  time. 

With  this  understanding  of  UF .  set,  it  should  be  clear  how  teqopt ’s  are  used.  Using 
sameset  on  two  sameas  fields  will  return  true  if  we  have  already  observed  that  the  two 
refinement  types  are  equal.  Using  sameset  to  search  the  differentfrom  fields  will  tell 
us  if  we  have  already  determined  that  two  refinement  types  are  different.  If  we  have  to 
compare  two  refinement  types,  and  the  teqopt  fields  do  not  make  it  clear  that  they  are 
either  equal  or  unequal,  then  we  do  the  comparison  using  whatever  expensive  enumerations 
are  necessary,  and  then  we  update  the  teqopt  fields  as  necessary  to  record  the  result  of  the 
comparison.  As  an  exception,  we  do  not  try  to  memoize  type  equality  for  refinement  types 
that  are  not  constant. 

This  strategy  works  well  in  practice.  The  most  expensive  aspect  is  searching  the 
dif  f  erentfrom fields.  We  can  improve  this  even  further  by  only  memoizing  type  equality 
when  expensive  iterations  are  involved  (that  is,  when  the  type  constructor  has  negative  type 
arguments).  Since  programs  often  have  many  refinements  of  simple  types  such  as  tuples, 
booleans,  and  lists,  and  few  refinements  of  higher-order  types,  this  usually  helps.  In  the 
boolmap  example  above,  memoizing  type  equality  would  avoid  all  comparisons  of  notfn 
with  itself  when  we  are  searching  the  generation  tables,  but  no  use  of  the  teqopt  field 
would  be  made  when  we  compare  the  refinements  of  bool  list. 

This  optimization  ought  to  make  a  difference  when  evaluating  a  fixed  point  requires 
comparing  function  objects  with  large  types.  This  optimization  can  be  turned  on  and 
off  by  setting  the  dont_teq_unionf  ind  flag,  and  experiments  with  this  flag  show  that 
this  optimization  rarely  makes  a  difference.  Memoizing  functional  refinement  types,  as- 
discussed  below,  makes  the  amount  of  work  saved  by  this  optimization  trivial  when  function 
types  are  fairly  small. 


7.2.4  Memoizing  Refinement  Types 

When  analyzing  typical  programs,  the  type  inference  algorithm  described  in  previous 
chapters  often  finds  the  interpretation  of  a  type  and  then  evaluates  that  interpretation  many 
times  at  the  same  point.  Since  we  represent  types  by  their  interpretations,  we  can  hope 
to  save  time  by  memoizing  these  interpretations.  This  means  that  after  the  first  time  we 
evaluate  the  function  at  a  given  point,  if  an  occasion  to  evaluate  it  at  the  same  point  arises 
again,  we  look  up  the  old  value  in  a  table  we  maintain  for  this  purpose  instead  of  repeating 
the  work.  The  implementation  does  this. 

The  most  straightforward  implementation  of  memo  tables  would  implement  the  tables 
as  association  lists,  and  always  use  type  equality  to  search  for  a  relevant  entry  in  the 
table.  The  present  implementation  does  indeed  implement  the  tables  as  association  lists, 
but  searching  the  tables  is  slightly  more  clever.  Since  type  equality  can  be  slow  when  types 
have  negative  arguments,  we  compare  types  with  negative  arguments  using  the  sameas  field 
of  the  teqopt;  this  is  essentially  the  same  as  using  pointer  equality,  except  that  if  two  types 
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have  been  found  equal  while  searching  pending  analysis  tables,  we  use  that  information 
when  searching  the  memo  tables. 

Memoization  of  refinement  types  can  be  turned  off  by  setting  the  dont_memoize  flag. 
This  optimization  does  help;  we  can  run  the  CHF  example  from  Chapter  1  in  22  seconds 
with  the  flag  clear,  and  27  seconds  with  the  flag  set. 

As  a  special  case,  we  use  a  simpler  algorithm  to  memoize  types  with  no  negative 
arguments.  In  this  case  the  argument  to  the  function  in  the  argument  to  Ref  Con  is  always 
the  empty  list,  so  we  can  omit  the  work  of  searching  the  memo  table  altogether. 

This  special  case  can  be  turned  off  by  setting  the  lazy.ref con  flag.  When  this  is  done, 
these  types  are  memoized  with  the  general-purpose  memoizer  only.  In  the  CNF  example 
from  Chapter  1,  there  are  many  simple  types  with  no  negative  arguments,  so  setting  the  flag 
causes  an  even  larger  slowdown  than  dont_memoize.  This  example  runs  in  22  seconds 
with  this  flag  clear  and  28.5  seconds  with  the  flag  set. 

Non-constant  types  are  not  entered  into  memo  tables  or  compared  with  types  in  memo 
tables. 


7.3  Instantiating  Refinement  Types 


Instantiating  refinement  types  is  straightforward  when  they  are  represented  explicitly.  For 
example,  instantiating  a  to  bool  in  the  refinement  type  (a—*  a)—*  a-*  a  yields 

(tt  -*  tt)  -►  tt  ->  tt  A 

(if A 

( T  (tool  *  T  tool )  >  T  Joof  >  T  bool  A 

(  -L  bool  *  -1-  bool )  *  -L  bool  *  -L  bool  • 

An  algorithm  for  this  is  straightforward:  simply  enumerate  all  refinement  type  substitutions 
refining  the  ML  type  substitution,  apply  each  of  them  to  the  original  refinement  type,  and 
take  the  intersection  of  all  the  results.  Unfortunately,  this  procedure  is  slow;  the  number  of 
refinement  type  substitutions  to  consider  grows  exponentially  as  a  function  of  the  number 
of  type  variables  to  be  instantiated.  In  this  section  we  give  an  instantiation  algorithm  that 
instantiates  lazily  represented  refinement  types  without  enumerating  all  possible  refinement 
type  substitutions.  The  correctness  proof  for  this  algorithm  is  future  work. 

The  purpose  of  this  section  is  Vs  make  the  instantiation  algorithm  intuitively  plausible 
and  to  describe  it  well  enough  to  permit  interested  people  to  attempt  to  prove  or  disprove 
soundness.  One  obstacle  to  the  soundness  proof  is  devising  specifications  for  the  various 
subroutines  in  the  algorithm  that  are  both  formal  and  correct.  All  specifications  below  will 
be  informal. 
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7.3.1  Instantiation  Example  and  Algorithm 

The  function 


fn  f:a  — ►  =>  In  x:a  =>  f[]  (f[]  x[]) 

has  the  refinement  type  scheme  V(a).(a  — >  a)  — >  a  — *  a.  Call  this  function  double.  Our 
example  consists  of  using  a  lazy  representation  of  refinement  types  to  determine  the  principal 
refinement  type  of  double  [ioo/]  not[]  (true  ()),  where  the  booleans  have  the  usual 
refinements  and  not  is  the  obvious  function  mapping  booleans  to  booleans.  As  the  argument 
in  Subsection  4.1.2  on  page  226  shows,  the  correct  result  is  T 4oo/. 

To  make  the  explanation  simple,  we  use  a  simplified  version  of  the  lazy  refinement  type 
representation  introduced  above: 

datatype  boolref  *  TT  I  FF  I  Bot  I  Top 
datatype  tp  =  Ground  of  boolref 
I  Later  of  (tp  ->  tp) 

|  Reftyvar 

In  this  datatype.  Ground  constructs  refinements  of  bool  in  the  obvious  way.  Later  is  a 
simplified  version  of  the  Ref  Con  constructor  that  only  applies  to  function  types;  Later  /  is 
the  refinement  type  with  the  interpretation  (as  defined  in  Chapter  2)  /.  The  value  constructor 
Reftyvar  stands  for  a  refinement  of  a  type  variable.  It  is  always  clear  from  context  which 
type  variable  Reftyvar  refines. 

To  conveniently  describe  types  in  terms  of  this  datatype,  we  will  need  an  inverse  for 

Later: 


exception  Bug  of  string 
fun  now  (Later  f)  -  f 

I  now  _  *  raise  Bug  "now" 

Using  this,  we  can  write  something  equivalent  to  the  representation  of  the  refinement  type 
of  double  that  would  arise  from  the  natural  type  inference  algorithm: 

Later  (fn  f  =>  Later  (fn  x  =>  (now  f)  ((now  f)  x))) 

With  the  exception  of  the  insertions  of  the  Later’s  and  now’s,  this  has  the  same  structure 
as  the  definition  of  double  itself.  This  is  not  surprising  since  refinement  type  inference  is  a 
form  of  abstract  interpretation  and  double  contains  no  value  constructors.  Here  we  assume 
that  the  refinement  type  given  for  f  will  always  refine  a  -» a  and  the  refinement  type  given 
for  x  will  always  refine  a ;  this  implies  the  type  passed  for  x  will  always  be  Reftyvar. 
(Later,  we  will  consider  an  alternative  valid  refinement  type  for  double  other  than  the  one 
that  would  arise  from  the  natural  type  inference  algorithm.)  We  can  also  give  the  type  for 
not[]  in  this  format: 
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let  fun  notfb  TT  **  FF 
I  notfb  FF  *  TT 
I  notfb  Top  »  Top 
I  notfb  Bot  =  Bot 

fun  notfa  (Ground  x)  =  (Ground  (notfb  x)) 

I  notfa  _  =  raise  Bug  "notfa" 
in  Later  notfa  end 

and  the  type  of  true  ()  is  Ground  TT. 

The  heart  of  the  instantiation  algorithm  we  will  describe  below  only  works  for  types 
with  no  negative  type  arguments.  Thus  the  first  step  toward  determining  the  type  for 
double[6oo/]  not[]  (true  ())  is  postponing  the  real  work  of  instantiation  until  we  are  left 
with  the  problem  of  instantiating  a  type  with  no  negative  type  arguments.  This  postponment 
is  necessary  for  the  correctness  of  the  algorithm  we  describe  below.  An  example  where  the 
algorithm  is  incorrect  if  this  step  is  omitted  appears  on  page  292. 

The  ML  type  type  of  double[&oo/]  is  ( bool  — *  bool)  — »  bool  — » bool,  which  has  negative 
type  arguments.  Thus  we  postpone  work;  the  refinement  type  generated  for  double[£oo/] 
is  simply  Later  (fn  f  *  =>  . . .),  where  we  will  fill  in  the  “. . in  a  moment. 

While  finding  the  type  for  double[6oo/]  not[],  we  will  strip  the  Later  from  the  type 
of  double[6ool]  and  pass  Later  notfa  to  the  resulting  function.  The  result  of  this  must 
be  a  refinement  of  bool  — ►  bool,  so  we  postpone  work  further  by  giving  this  the  form 
Later  (fn  x’  *>  ...).  This  implies  the  refinement  type  of  double[6oo/]  must  have  the 
form  Later  (fn  f'  =>  Later  (fn  x’  =>  ...)). 

While  finding  the  type  for  double(6oo/]  not[]  (true  ()),  we  will  strip  the  Later  from 
the  type  of  doublefioo/]  not[]  and  pass  Ground  TT  to  the  resulting  function.  The  result 
will  refine  bool,  which  has  no  negative  type  arguments;  thus  we  are  finished  with  the  stage 
where  we  are  postponing  the  real  work  of  instantiation. 

Once  we  have  f  *  and  x  * ,  we  will  search  for  the  least  substitution  mapping  type  variables 
to  refinement  types  that  is  consistent  with  the  types  f  ’  and  x ' .  In  our  example,  f  ’  is  bound 
to  the  type  of  not  []  as  described  above  and  x  ’  is  bound  to  Ground  TT.  Given  a  substitution 
to,  we  can  convert  f  ’  and  x’  into  refinement  types  we  can  pass  for  f  and  x  in  the  before- 
instantiation  type  of  double.  We  call  this  process  “reshaping”. 

We  will  talk  about  two  different  reshaping  processes.  One  is  called  reshapeab  because 
it  reshapes  an  after-instantiation  refinement  type  like  f  ’  into  a  before-instantiation  refine¬ 
ment  type  like  f .  Another  is  called  reshapeba  because  it  reshapes  a  before-instantiation 
refinement  type  into  an  after-instantiation  refinement  type.  These  two  procedures  are  mu¬ 
tually  recursive.  They  refer  to  two  global  variables:  to  is  the  present  substitution  of 
refinement  types  for  type  variables,  and  mo  is  a  fixed  substitution  of  ML  types  for  type 
variables. 

As  described  above,  we  are  looking  for  a  least  to  that  is  consistent  with  the  types  f  ’ 
and  x\  We  perform  this  search  by  starting  with  the  least  ro  and  revising  it  as  necessary 
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until  it  is  consistent  with  the  types  f  *  and  x\  The  code  below  indicates  that  revisions  are 
necessary  by  raising  an  exception;  specifically,  the  exception  TooSmall  (a,  r)  is  raised 
to  indicate  that  to  should  be  replaced  by  ra[a  :=  r]. 

Although  we  have  no  formal  specification  for  reshapeab  and  reshapeba,  we  can 
formally  describe  a  few  invariants  used  in  it.  Whenever  reshapeab  r  t  is  called,  r  C 
mo(t).  When  evaluating  reshapeab  r  t  raises  no  exception,  the  result  refines  t.  Whenever 
reshapeba  r  t  is  called,  rdf,  and  any  result  refines  mcr(t). 

fun  reshapeab  (Later  /)  (f i  — » $2)  * 

Later  (fn  r  =>  reshapeab  (/  (reshapeba  r  t j))  t?) 
i  reshapeab  r  bool  =  r 
I  reshapeab  r  a  = 
if  subtypep  r  ro(a)  mcr(a)  then 
Reftyvar 
else 

raise  TooSmall  (a,  joinf  r  rtr(a)  ma(a)) 
and  reshapeba  (Later  /)  (t\—*t2)  3 

Later  (fn  r  =>  reshapeba  (/  (reshapeab  r  t{))  t2) 

I  reshapeba  r  bool  =  r 
I  reshapeba  r  a  =  r<r(a) 

To  solve  the  instantiation  problem  at  hand,  we  will  use  reshapeab  to  convert  f  *  and  x  ’ 
to  the  f  and  x  expected  in  the  uninstantiated  type  for  double.  Then  we  will  use  reshapeba 
to  convert  the  value  returned  from  the  type  for  double  into  a  refinement  of  bool. 

Now  we  shall  apply  these  algorithms  to  f  ’  and  x ' .  For  the  instantiation  problem  we 
have  in  mind,  mtr  is 

[a  :=  bool]; 

we  will  leave  to  undetermined  for  the  time  being.  Evaluating  reshapeab  f  ’  (a  — ►  a) 
and  simplifying  yields 

Later  (fn  r  => 

if  subtypep  (notfa  (r<r(a)))  rer(a)  bool  then 
Reftyvar 

else  raise  TooSmall  (a,  joinf  r  To(a)  bool)) 

and  evaluating  reshapeab  x’  a  and  simplifying  yields 

if  subtypep  (Ground  TT)  ro(a)  bool  then 
Reftyvar 
else 

raise  TooSmall  (a,  joinf  (Ground  TT)  ro(a)  bool) 
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We  start  by  assuming  that  ra  is  the  least  possible  substitution  that  refines  rrur,  which  is 

[a  :=  Ground  Bot]. 

With  this  assumption,  determining  reshapeab  x*  a  immediately  raises  the  exception 

TooSmall  (a.  Ground  IT), 


so  we  revise  ra  to 


a  :=  Ground  TTj. 


Starting  with  the  new  ra,  we  find  that  reshapeab  f  ’  a  yields 


Later  (In  r  => 

if  subtypep  (notfa  (Ground  TT))  (Ground  TT)  bool  then 
Ref tyvar 

else  raise  TooSmall  (at,  joinf  r  (Ground  TT)  bool)) 


and  reshapeab  x*  a  yields  a.  Now  we  pass  these  two  values  for  f  and  x  respectively  in 
(now  f)  ((now  f)  x);  the  definition  of  f  then  raises  the  exception 

TooSmall  (a,  Ground  Top). 

Thus  we  revise  the  substitution  to 


[a  :=  Ground  Top] 

and  try  again.  This  time  no  exceptions  are  raised,  and  the  value  returned  by 

(now  f)  ((now  f)  x) 

is  Ref  tyvar.  Then  we  call  reshapeba  Ref  tyvar  a,  which  yields  Ground  Top,  which  is 
our  solution. 

If  we  do  not  postpone  as  much  work  as  possible,  this  algorithm  gives  incorrect 
results.  For  example,  suppose  we  want  to  instantiate  a  to  bool  in  refinement  type 
Later  (fn  x  =>  x)  interpreted  as  a  refinement  of  a-*  a.  If  we  do  not  postpone  any 
work,  we  start  with  the  assumption  ra  =  [a  :=  Ground  Bot]  and  end  with  the  same  sub¬ 
stitution.  The  result  from  instantiation  is  reshapeba  (Later  (fn  x  =>  x))  (a  — » a), 
which  simplifies  to 

Later  (fn  x'  =>  reshapeba  (reshapeab  x'  a)  a) 
which  in  turn  simplifies  to 


Later  (fn  x'  =>  if  subtypep  x'  (Ground  Bot)  bool  then  Ground  Bot  else 

raise  TooSmall  (a,  x')). 
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Thus  instantiation  returns  a  refinement  type  that  will  raise  TooSmall  under  some  conditions; 
this  is  clearly  malformed. 

To  finish  the  instantiation  algorithm,  we  will  describe  the  code  wrapped  around  the 
definitions  of  reshapeab  and  reshapeba,  and  we  will  describe  and  fix  one  situation  where 
the  above  code  is  incorrect.  The  resulting  procedure  has  no  known  bugs  but  no  correctness 
proof. 

There  are  two  parts  to  the  remaining  code:  the  procedure  for  postponing  work  until  we 
have  no  negative  type  arguments  and  the  loop  searching  for  an  appropriate  re.  Both  of 
these  are  straightforward;  we  will  present  postponing  the  work  first,  since  it  is  outermost.  In 
the  following  definition,  the  call  inst  r  me  t  instantiates  the  refinement  type  r  according 
to  the  substitution  me  mapping  type  variables  to  ML  types,  under  the  assumption  that  r 
refines  t.  In  the  code  below,  we  assume  that  mapsubst  /  e  constructs  a  substitution  with 
the  same  domain  as  e  and  for  all  a  in  that  domain,  (mapsubst  /  e)(a)  =  f(e(a)).  The 
botfn  function  was  introduced  on  page  1 18  for  computing  the  least  refinement  of  any  ML 
type.  We  will  fill  in  the  definition  of  the  function  looper  later. 


fun  inst  r  me  t  = 

let  fun  instargs  args  argtys  r  — *•  t2)  = 

Later  (fn  arg  =>  instargs  ( arg  : :  args )  (ii  : :  argtys)  r  t2) 
I  instargs  args  argtys  r  t  = 
let  fun  looper  re  -  ... 
in 

looper  (mapsubst  botfn  me) 

end 

in 

instarg3  []  []  r  t 

end 


The  above  code  is  straightforward;  it  simply  accumulates  refinement  types  and  ML  types 
in  the  args  and  argtys  arguments  until  the  refinement  type  does  not  refine  a  functional  type, 
and  then  it  calls  looper  with  a  suitable  initial  value  for  re. 

Now  we  can  give  a  definition  of,  the  function  looper  that  iterates  to  find  the  least 
substitution  consistent  with  the  constraints.  This  definition  has  the  free  variables  args , 
argtys,  r,  and  t.  In  the  code  below,  rev  is  the  standard  function  for  reversing  lists. 
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fun  looper  r<r  ■ 

let  exception  TooSmall  of  string  *  tp 
fun  reshapeab  ...  =  ... 
and  reshapeba  ...  =  ... 

fun  call  (Later  /)  ( argl  : :  argrest)  ( atl  : :  atrest)  * 
call  (/  (reshapeab  argl  atl))  argrest  atrest 
I  call  x  []  []  ■  reshapeba  x  t 
I  call  _  _  _  *  raise  Bug  "call" 
in 

(call  r  (rev  args)  (rev  argtys) 
handle 

TooSmall  (var,  tp)  => 

looper  ( ra[var  :=  ip]) 

end 

This  code  is  fairly  straightforward;  it  uses  the  stored  argument  lists  to  repeatedly  call  the 
uninstantiated  refinement  type,  changing  rcr  as  indicated  by  the  TooSmall  exceptions  until 
r<r  is  a  usable  substitution. 

The  symmetry  between  reshapeab  and  reshapeba  is  pleasing,  and  the  algorithm 
specified  above  seems  to  work  if  all  refinement  types  are  generated  by  a  natural  algorithm 
starting  with  expressions  without  any  explicit  refinement  type  declarations,  and  all  argu¬ 
ments  are  used.  Unfortunately,  making  an  algorithm  that  appears  to  work  in  general  breaks 
the  symmetry.  For  example,  this  1st  statement 

let  too  -  A(a).fn  f  :a— »a  =>  fn  x:a  *>  x[] 
in  ...  end 

will  add  the  refinement  type  scheme 

V(a).(a  — »  a)  — >  a  — ►  a 

to  the  environment  before  it  typechecks  the  expression  within  the  scope  of  the  let  statement. 
This  is  the  same  as  the  refinement  type  scheme  resulting  from  the  double  example  above, 
except  now  the  representation  of  the  refinement  type  that  results  from  the  natural  algorithm 
is 


Later  (fn  f  =>  Later  (fn  x  =>  x)). 

Since  f  is  never  used,  the  above  instantiation  algorithm  will  not  inspect  the  type  of  f . 
This  is  clearly  wrong;  since  the  refinement  type  of  f  oo  is  the  same  as  the  refinement  type 
of  double,  instantiating  the  type  of  f  oo  should  pull  the  same  information  out  of  f  that 
instantiating  the  refinement  type  of  double  does. 

Suppose  we  used  the  present  algorithm  to  determine  the  type  of 

foo[6oo/]  not[]  (true  ()). 
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The  instantiation  algorithm  would  start  with  ra  equal  to 

[a  :=  Ground  Bot]. 

As  in  the  earlier  example,  this  would  be  observed  to  be  inconsistent  with  the  type  of  true  (), 
so  we  would  revise  ra  to 

[a  :=  Ground  TT]. 

Here  the  resemblance  to  the  earlier  example  ends,  because  unlike  that  example  the  type  of 
not[]  is  never  examined;  the  algorithm  is  finished  and  the  result  is  Ground  TT. 

Intuitively,  it  seems  plausible  that  the  problem  is  that  the  final  substitution  is  not 
consistent  with  the  type  of  not[];  in  other  words,  if  we  use  reshapeab  to  de-instantiate  the 
type  of  not[]  with  the  final  ra,  the  resulting  type  raises  an  exception  for  all  inputs.  Since 
the  interpretation  of  a  refinement  is  always  a  monotone  function,  it  will  fail  for  all  inputs  if 
and  only  if  it  fails  for  the  least  input.  Thus  we  can  detect  this  problem  by  passing  the  least 
refinement  of  the  input  ML  type  to  the  function  and  discarding  the  result;  any  problems  will 
be  dealt  with  as  a  consequence  of  the  resulting  TooSmall  exception.  Thus  we  rewrite  the 
function  case  of  reshapeab  as  follows: 

fun  reshapeab  (Later  /)  t\  —*t2  = 

(reshapeab  (/  (botfn  (applysubst  ma  t\)))  tzi 
Later  (fn  arg  ->  instargs  ( arg  : :  args)  (<i  : :  argtys )  r  t2)) 

With  this  rewritten  case,  the  algorithm  has  no  known  bugs.  Assembling  the  pieces  of  code 
appearing  in  this  chapter  yields  the  completed  algorithm  in  Figure  7.1. 


7.3.2  Memoizing  Instantiation 

Every  variable  is  instantiated  before  it  is  used,  although  the  instantiation  is  often  trivial.  This 
makes  memoizing  instantiation  very  important.  If  we  do  not  do  this,  then  each  type  is  created 
anew  every  time  a  variable  is  referenced;  these  newly  created  types  have  empty  memo  tables, 
so  unmemoized  instantiation  undoes  many  of  the  other  memoization  optimizations.  The 
implementation  normally  memoizes  instantiation;  the  flag  dont_memoize_inst  can  be  set 
to  turn  this  off. 

As  implemented,  the  instantiation  algorithm  quickly  deals  with  nonpolymorphic  types 
by  using  a  special  case.  Thus  the  CNF  example  above  cannot  be  used  to  illustrate  this 
optimization.  We  can  illustrate  it  by  using  a  simple  polymorphic  type,  such  as  polymorphic 
lists,  even  if  we  make  no  interesting  use  of  the  polymorphism.  For  example,  if  we  distinguish 
even  length  lists  from  odd  length  lists  and  empty  lists  from  nonempty  lists,  then  a  simple 
function  for  appending  lists: 
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fun  inst  r  ma  t  * 

let  fun  instargs  args  argtys  r  (£1  — *  t2)  * 

Later  (fn  arg  a>  instargs  ( arg  : :  args)  ( t\  : :  argtys)  r  t2) 

I  instargs  args  argtys  r  t  * 
let  fun  looper  rer  =■ 

let  exception  TooSmall  of  string  *  tp 
fun  reshapeab  (Later  /)  t\  — *  t2  * 

(reshapeab  (/  (botfn  (applysubst  me r  tt)))  t2 ; 
Later  (fn  arg  => 

instaurgs  (art/  : :  args)  (^  : :  argtys)  r  t2)) 
I  reshapeab  r  bool  a  r 
I  reshapeab  r  a  = 
if  subtypep  r  r<r(a)  mo'(a)  then 
Reftyvar 
else 

raise  TooSmall  (a,  joinf  r  r<r(a)  m<r(a)) 
and  reshapeba  (Later  /)  (£1  — ►  £2)  s 

Later  (fn  r  =>  reshapeba  (/  (reshapeab  r  £!))  £2) 

I  reshapeba  r  bool  *  r 
I  reshapeba  r  a  a  r<r(a) 

fun  call  (Later  /)  (aryl  : :  argrest)  (atl  : :  atrest)  * 
call  (/  (reshapeab  argi  atl))  argrest  atrest 
I  call  x  []  []  =  reshapeba  x  t 
I  call  _  _  _  58  raise  Bug  "call” 
in 

(call  r  (rev  args)  (rev  argtys) 
handle 

TooSmall  ( var ,  tp)  -> 

looper  ( r<r[var  :=  tp]) 

end 


in 

looper  (mapsubst  botfn  m<r) 

end 


in 

instargs  []  []  r  t 
end 


Figure  7.1:  Instantiation  algorithm. 
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fix  ap:a  list— *  a  list— *  a  list  => 
fn  x:a  list  3>  fn  y:a  list  => 
case  x  of 

cons  3>  fn  hdtl:a*a  /is l  => 

cons  (elt_l_2  hdtl,  ap  (elt_2_2  hdtl)  y[]) 

I  nil  3>  fn  xitunit  *>  y[] 
and:  a  list 

has  a  refinement  type  that  is  an  intersection  of  49  components.  Computing  this  type  takes 
7.3  seconds  with  dont .memo ize.inst  turned  off,  or  60  seconds  with  dont  _memoize_inst 
turned  on. 


7.4  Analyzing  Rectype  Declarations 

Most  of  the  code  for  analyzing  rectype  declarations  is  either  obvious  or  an  implementation 
of  some  algorithm  in  Chapter  3.  A  brief  description  of  the  known  shortcomings  of  the 
implementation  follows. 

No  attempt  has  been  made  to  enforce  Assumption  5.29  (Predefined  Intersection  Dis- 
tributivity)  on  page  259.  Sometimes  this  assumption  does  not  hold  and  the  implementation 
behaves  strangely;  for  example,  with  the  usual  declaration  for  bool  and  this  declaration: 

datatype  a  d  a  C  of  bool— *  a 
rectype  a  z  3  C  (tt— *a)  I  C  (ff  — »a); 

the  implementation  infers  that  C  ((fn  x  *>  x)  <J  (tt  — >  tt))  has  the  principal  type  tt  z 
and 

C  ((fn  x  =>  x)  <  (ff-*ff)) 
has  the  principal  type  ff  z,  but  it  also  infers  that 

C  ((fn  x  *>  x)  <1  (ff—>ff/\  tt —*  tt)) 

has  the  principal  type  T  j This  means  that  the  behavior  inferred  for  C  is  not  monotone, 
a  serious  bug.  Fixing  this  by  inferring  a  different  behavior  for  C  seems  more  satisfying  than 
fixing  it  by  outlawing  declarations  similar  to  this  one,  but  the  best  way  to  do  this  is  not 
immediately  clear.  In  this  example,  the  instantiation  algorithm  is  misbehaving  in  circum¬ 
stances  where  Predefined  Intersection  Distributivity  is  false;  thus  it  is  reasonable  to  guess 
that  any  soundness  proof  for  the  instantiation  algorithm  will  use  Predefined  Intersection 
Distributivity. 

When  we  infer  the  predefined  splitting  relation  from  the  rectype  declaration,  we 
assume  without  proof  that  it  suffices  to  consider  exactly  one  most  informative  principal 
split  of  each  constructor.  The  implementation  uses  a  brute  force  search  to  find  all  of  the 


298 


CHAPTER  7.  IMPLEMENTATION 


“plausible”  principal  splits  of  each  constructor;  in  this  context  a  proposed  split  is  plausible 
if  no  two  types  in  it  are  comparable,  and  all  of  the  fragments  are  less  than  the  constructor 
of  which  they  are  proposed  fragments.  Then  another  brute  force  search  lists  fixed  points  of 
the  inference  system  in  Figure  3.8  on  page  207  where  we  assume  each  new  refinement  type 
constructor  has  at  most  one  split  in  the  fixed  point.  We  assume  without  proof  that  the  most 
informative  of  these  is  an  appropriate  predefined  splitting  relation. 


7.5  Differences  Between  Implementation  and  Theory 

There  are  a  few  differences  between  the  implementation  and  the  theory  that  do  not  fit  neatly 
into  any  of  the  topics  listed  above. 

We  treat  case  statements  where  the  case  object  is  a  variable  specially.  For  example, 
suppose  we  have  the  declarations 

datatype  maybe  -  true  of  tunit  I  false  of  tunit  I  maybe  of  tunit 
rectype  tt  =  true  (tunit) 
and  ff  -  false  (tunit) 
and  tf  =  true  (tunit)  I  false  (tunit) 
datatype  forget  =  C  of  maybe 

Then  the  best  type  for  x  from 

val  x  -  case  C  (true  ())  of  C  =>  fn  y  =>  y  end:  maybe 

is  Tmasi«.  Reading  the  type  system  strictly,  the  statement 

case  x  of 

true  =>  fn  _  =>  false  () 

I  false  =>  fn  _  =>  x 
I  maybe  =>  fn  _  =>  false  () 
end :  maybe ; 

has  the  best  type  Tm->4e  because  in  the  false  case,  the  type  of  the  variable  x  is  still 
since  case  statements  do  not  affect  variable  bindings.  This  surprises  many  users  because 
the  case  statement  obviously  always  returns  false  ().  To  eliminate  the  surprise,  when  the 
case  object  is  a  variable  (x  in  the  example),  the  implementation  binds  that  variable  to  a  better 
type  while  analyzing  each  branch  of  the  case  statement.  The  better  type  is  computed  by 
applying  the  constructor  for  each  case  to  the  inferred  type  of  its  argument;  in  this  example, 
the  constructor  is  false  and  the  inferred  type  of  the  argument  is  the  unique  refinement 
of  tunit,  so  x  is  bound  to  the  type  ff  within  the  scope  of  the  false  branch  of  the  case 
statement. 
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Another  practical  inaccuracy  in  the  implementation  is  that  types  appearing  at  the  top 
level  are  not  split.  For  example,  assuming  the  usual  definitions  of  the  booleans,  not,  and 
or,  splitting  causes  the  expression 

(fn  x  =>  (or  x  (not  x)))  ((true  ())  <  T 

to  get  the  type  tt.  However,  if  the  declaration 

val  x  =  (true  ())  <1  T&oo/; 

is  followed  by  the  expression 


or  x  (not  x), 

then  the  latter  expression  only  gets  the  type  T  4 We  do  this  because  the  implementation 
of  splitting  requires  reanalyzing  the  entire  scope  of  the  binding  for  each  fragment  of  the 
split;  if  the  scope  is  the  entire  future  history  of  the  type  checker,  then  we  cannot  afford  to 
do  this. 


Chapter  8 

Conclusion,  Critical  Evaluation,  and 
Future  Work 


Refinement  type  inference  shows  signs  of  being  a  useful  type  inference  system.  The 
types  have  an  intuitively  appealing  meaning,  type  inference  can  be  described  with  read¬ 
able  inference  rules,  type  inference  provably  has  some  useful  properties,  and  a  working 
implementation  exists. 

As  with  any  work  of  this  size,  this  one  has  shortcomings.  Some  of  the  shortcomings 
represent  tradeoffs  made  to  ensure  that  refinement  type  inference  is  efficiently  decidable. 
Other  shortcomings  could  be  remedied  by  experimenting,  adding  new  language  features, 
proving  more  theorems,  or  by  improving  the  implementation. 


8.1  Tradeoffs  Made  for  Tractable  Type  Inference 

There  are  numerous  situations  where  a  program  has  a  property  that  can  be  expressed  as  a 
refinement  type,  but  refinement  type  inference  cannot  infer  as  strong  a  type  as  one  would 
like. 

Refinement  type  inference  only  makes  the  distinctions  specified  by  the  programmer  in 
rectype  declarations.  Even  if  a  true  property  of  a  program  can  be  described  in  terms  of 
those  distinctions,  if  one  must  use  other  distinctions  to  infer  this,  refinement  types  cannot 
infer  that  the  property  is  true.  For  example,  consider  the  declarations  from  Chapter  1  that 
distinguish  lists  of  length  zero,  one,  and  two  or  more  from  each  other: 

datatype  a  list  -  nil  I  cons  of  a  *  a  list 
rectype  a  empty  =  nil 

and  a  singleton  -  cons  (a,  nil) 

and  pi  long  ■  cone  (a,  cons  (a,  a  T^t)) 

and  a  ±iut  =  bottom  (list) 
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Then  the  function 

fn  x  =*>  case  cons  (x,  cons  (x,  nil))  of 

cons  (_,  cons  (_,  nil))  ->  cons  (x,  nil) 

I  _  *>  nil 

will  always  return  a  list  of  length  one,  but  it  will  not  have  the  refinement  type 
a-* a  singleton  because  we  can  only  determine  that  the  function  will  always  return  a 
list  of  length  one  by  recognizing  a  list  of  length  exactly  two,  and  we  have  assumed  that  no 
rectype  declaration  has  been  made  that  will  distinguish  lists  of  length  exactly  two.  It  is 
easy  to  express  this  distinction  as  a  rectype  statement: 

rectype  a  twolist  3  cons  (a,  cons  (a,  nil)) 

In  general,  rectype  statements  are  descriptions  of  regular  tree  automata  [GS84],  and 
sets  of  values  that  are  not  recognizable  by  a  finite  tree  automaton  cannot  be  described  with 
a  rectype  statement.  For  example,  we  can  make  the  usual  distinction  among  the  booleans 

datatype  bool  3  true  of  tunit  |  false  of  tunit 
rectype  tt  3  true  (runt'Z) 
and  ff  3  false  ( runit ) 

and  write  a  function  to  test  whether  two  lists  have  the  same  length: 

fun  samelength  (cons  (x,  tlx))  (cons  (y,  tly))  3  samelength  tlx  tly 
I  samelength  nil  nil  3  true 
I  samelength  _  _  3  false 

With  this  definition,  for  any  list  l  we  know  that  samelength  /  /  returns  true,  but  we 
cannot  declare  any  finite  set  of  distinctions  within  list  to  cause  samelength  to  have  the 
refinement  type  T u,t  — ►  T u,t  — >  tt.  The  problem  here  is  that  the  infinite  set  of  possible 
lengths  cannot  be  encoded  in  the  state  of  a  finite  tree  automaton.  Similarly,  refinement  type 
inference  cannot  reason  about  closed  expressions  in  a  representation  of  the  lambda  calculus 
because  the  infinite  number  of  possible  sets  of  bound  variables  cannot  be  encoded  in  the 
state  of  a  finite  tree  automaton. 

Another  shortcoming  is  that  refinement  type  inference  does  not  know  when  a  function 
is  deterministic  and  unaffected  by  side  effects.  Thus,  if  l  is  some  list,  we  will  not  be  able  to 
infer  that  the  expression 

if  samelength  l  l  then  true  else  not  (samelength  l  l ) 

has  the  refinement  type  tt.  If  refinement  types  were  able  to  use  the  information  that 
samelength  is  deterministic  and  does  not  use  side  effects,  it  could  infer  that  the  if 
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statement  has  the  type  tt  even  if  it  could  not  infer  that  sauna  length  l  l  can  be  given  the 
type  tt. 

A  different  shortcoming  stems  from  the  fact  that  refinement  type  inference  is  defined  in 
terms  of  expressions  with  explicit  ML  types,  but  the  programmer  writes  expressions  with 
implicit  ML  types.  In  general,  a  term  with  implicit  ML  types  may  correspond  to  multiple 
terms  with  explicit  ML  types.  To  predict  the  behavior  of  refinement  types,  the  programmer 
needs  to  know  which  one  of  these  the  compiler  will  select.  Fortunately,  the  prototype 
implementation  (and  every  Standard  ML  implementations  that  uses  the  simplest  algorithm) 
always  selects  the  explicitly  typed  term  containing  the  most  general  types. 

The  need  to  insert  a  rectype  declaration  before  refinement  type  inference  provides 
more  information  than  ordinary  ML  type  inference  can  also  be  regarded  as  a  shortcoming. 
However,  it  is  hard  to  imagine  doing  without  rectype  declarations.  In  the  normal  case, 
refinement  type  inference  will  be  used  to  find  errors  in  a  recently  modified  program. 
Analyzing  the  program  to  automatically  find  the  important  distinctions  to  make  is  likely 
to  be  hopeless  when  the  program  is  incorrect.  The  often-suggested  option  of  omitting 
rectype  statements  and  instead  automatically  creating  one  refinement  containing  each 
value  constructor  is  unworkable;  refinement  type  inference  will  give  some  information  in 
this  case,  but  the  information  will  rarely  be  useful.  For  example,  it  would  not  have  been 
useful  for  any  of  the  examples  in  the  introduction. 


8.2  Experience  Yet  to  Be  Gained 

Sometimes  it  is  not  clear  which  distinctions  need  to  be  made  in  a  rectype  declaration  to 
get  the  desired  conclusion.  In  the  function 

fun  lastcons  (last  as  cons  (hd,  nil))  =  last 
I  lastcons  (cons  (hd,  tl))  =  lastcons  tl 

we  need  to  use  a  rectype  declaration  to  distinguish  lists  of  length  two  to  be  able  to  infer 
that  lastcons  has  the  type  a  T u,t  — >  a  singleton.  If  we  give  the  type  of  lists  of  length  two 
the  name  a  long,  the  following  argument  shows  why  we  need  to  distinguish  a  long  to  get 
the  best  type  for  lastcons;  All  values  of  type  a  T n,t  are  in  one  of  a  empty,  a  singleton, 
or  a  long.  Each  of  these  cases  falls  squarely  into  one  of  the  branches  of  the  definition  of 
lastcons;  if  the  argument  is  of  type  a  long,  then  we  will  always  get  to  the  recursive  call 
lastcons;  if  the  argument  is  of  type  a  nngleion,  then  we  return  the  argument;  and  if  the 
argument  is  in  a  empty,  then  we  raise  an  exception  because  of  a  missing  case. 

If  we  omit  the  declaration  of  long,  then  we  can  no  longer  say  that  all  values  of  type 
a  T u,t  are  in  one  of  several  smaller  types.  If  the  argument  to  lastcons  has  type  a  T u,t, 
then  the  first  case  of  lastcons  is  reachable,  and  we  return  last,  which  is  the  argument  to 
lastcons  and  therefore  has  the  type  o  T u,t.  Thus,  from  the  viewpoint  of  type  inference, 
lastcons  appears  to  be  able  to  return  a  value  of  a  T u,t.  This  could  be  fixed  by  a  more 
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careful  understanding  of  how  patterns  bind  to  variables  that  gives  last  the  type  a  singleton 
in  this  case,  or,  as  we  mentioned  in  the  previous  paragraph,  it  could  be  fixed  by  adding  the 
refinement  type  long. 

As  larger  programs  are  checked  with  refinement  type  inference,  the  programmer  will 
become  more  experienced,  but  there  will  also  be  greater  opportunity  for  surprising  scenarios 
like  the  one  described  in  the  previous  paragraph  to  happen.  It  is  unclear  whether  this  process 
will  lead  to  sufficiently  rare  surprises  in  the  long  run;  more  experience  is  necessary. 

More  experience  is  also  necessary  to  determine  how  fast  and  how  useful  refinement  type 
inference  will  be  for  large  programs.  The  largest  program  run  through  the  type  checker  so 
far  is  the  conjunction  normal  form  example  in  Section  1.2,  which  is  only  50  lines  of  SML 
code. 


8.3  Future  Work  in  Language  Design 


The  correct  interaction  between  refinement  types  and  signatures  is  not  clear.  For  example, 
suppose  we  have  a  structure  List  that  implements  lists  and  operations  on  them  such  as 
append,  and  suppose  another  structure  uses  List  and  uses  a  statement  to  make  a  distinction 
between  empty  and  nonempty  lists.  Getting  the  best  possible  refinement  type  for  append 
in  the  second  structure  requires  re-analyzing  the  code  in  the  context  of  the  added  rectype 
statement;  assuming  that  type  inference  respects  the  privacy  of  List,  re-analyzing  the  code 
will  require  repeating  the  code  in  the  second  structure,  which  is  poor  software  engineering.. 

Another  option  would  be  to  allow  List  to  declare  the  implementation  of  append  in  its 
signature  to  give  type  inference  permission  to  re-analyze  append  as  necessary  when  new 
rectype  declarations  are  added.  Putting  expressions  in  signatures  is  a  big  change  to  SML; 
more  work  is  necessary  to  determine  whether  this  is  worthwhile. 

Some  data  types  such  as  string  and  int  are  predefined  rather  than  declared  with  a 
datatype  statement.  It  makes  sense  to  have  refinements  of  these;  for  example,  we  could 
imagine  distinguishing  positive  integers,  negative  integers,  and  zero  from  each  other.  How¬ 
ever,  this  will  require  a  declaration  other  than  a  rectype  statement,  since  rectype  state¬ 
ments  rely  upon  having  a  finite  number  of  constructors  for  each  data  type.  It  may  be 
worthwhile  to  find  some  other  way  to  declare  refinements  of  predefined  data  types. 

If  we  omit  the  declaration  of  long  in  the  list  example,  lastcons  does  not  get  the  right 
type.  Adding  long  brings  about  the  right  result  because  we  can  then  infer  that  all  values 
in  tt  list  are  in  one  of  the  types  tt  empty,  tt  singleton,  or  tt  long;  without  long,  there  are 
values  such  as  cons  (true  (),  cons  (true  (),  nil))  that  are  in  a  list  but  are  not  in 
any  smaller  type.  The  example  with  cnf  is  not  analogous;  we  can  infer  an  accurate  type  for 
toCnf  without  having  a  refinement  type  that  represents  all  boolean  expressions  that  are  not 
in  CNF.  In  general,  small  variations  in  the  rectype  declaration  have  a  subtle  effect  on  the 
outcome  of  refinement  type  inference.  Perhaps  some  useful  rules  of  thumb  will  arise  from 
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experiments  with  larger  programs. 

Every  visible  r«ctype  declaration  increases  the  number  of  cases  that  refinement  type 
inference  must  examine  and  therefore  slows  down  type  inference.  Thus  it  is  very  important 
to  have  good  mechanisms  for  restricting  the  scope  of  a  rectype  declaration  to  a  small 
extent  of  code.  The  problem  with  this  is  that  it  is  not  immediately  obvious  what  should 
happen  when  we  leave  the  scope  of  a  rectype  declaration.  For  example,  suppose  we  have 
the  declarations  of  bool,  tt,  and  ff  on  page  301  and  consider  the  statement 

let  datatype  a  Hat  -  nil  I  cons  of  (a  *  a  list) 
val  x  =  cons  (true,  nil) 
in 

let  rectype  a  tv  -  nil  I  cons  [a*  a  od) 
and  a  od  =  cons  of  (a  *  a  ev) 
in 

(x  <J  tt  od; 
cons  (true,  nil)) 

end 

end 

In  Standard  ML,  the  type  constructor  Hat  becomes  anonymous  once  we  leave  the  scope  of 
the  outer  let  statement;  this  means  that  the  type  still  exists,  but  it  cannot  be  named  in  type 
declarations.  Should  the  same  happen  to  the  recursive  type  constructors  ev  and  od  when 
we  leave  the  scope  of  the  outer  let  statement?  The  practical  and  theoretical  consequences 
of  this  have  not  been  explored. 

It  would  be  better  if  the  specification  of  the  meaning  of  rectype  declarations  in  Chap¬ 
ter  3  were  more  declarative.  Also,  because  many  properties  of  regular  tree  sets  are  ef¬ 
fectively  decidable,  it  is  possible  in  principle  to  do  perfect  reasoning  about  rectype  dec¬ 
larations  that  do  not  mention  function  types.  An  example  of  this  weakness  of  rectype 
declarations  as  currently  specified  is  on  page  193.  It  would  be  more  satisfying  to  have  a 
specification  of  the  meaning  of  rectype  statements  that  was  as  accurate  as  possible  in  that 
case. 


8.4  Future  Theoretical  Work 

The  soundness  theorem  in  Chapter  2  states  that  if  we  evaluate  a  closed  expression  to  get 
a  value,  then  the  value  has  any  refinement  type  the  closed  expression  did.  It  does  not 
immediately  follow  that  every  time  we  evaluate  a  subexpression  of  the  form  e  <  r,  all 
values  computed  for  e  actually  had  the  type  r.  A  more  ambitious  soundness  proof  would 
show  this. 

A  version  of  refinement  type  inference  that  deals  with  imperative  features  such  as 
references  exists  and  has  a  soundness  proof,  but  has  not  yet  been  written  up. 
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The  type  inference  system  in  Figure  3.8  for  deriving  the  splitting  relation  from  rectype 
statements  is  not  directly  implementable.  The  prototype  implementation  does  something 
that  seems  to  work  well  in  practice,  but  it  needs  to  be  verified. 

Likewise,  the  instantiation  algorithm  used  by  the  implementation  seems  to  work  well 
in  practice  but  it  needs  to  be  verified. 


8.5  Future  Implementations 

The  present  implementation  uses  memo  tables  in  many  places  to  improve  performance. 
These  memo  tables  are  all  implemented  as  lists;  profiling  shows  that  the  implementation 
spends  80%  of  its  time  searching  these  lists.  This  could  be  sped  up  dramatically  by  using 
arrays  and  an  appropriate  hashing  scheme. 

The  implementation  does  not  use  true  SML  syntax.  For  instance,  the  syntax  for  defining 
functions  is  separate  from  the  syntax  for  destructuring  data  types.  Also,  constant  value  con¬ 
structors  like  true  are  not  permitted;  instead,  every  value  constructor  takes  one  argument, 
so  the  best  we  can  do  is  true  (). 

The  theory  allows  for  four  ways  a  type  variable  can  appear  as  an  argument  to  a  poly¬ 
morphic  data  type  constructor:  positive,  negative,  ignored,  or  mixed.  We  only  implement 
positive  and  negative.  Ignored  arguments  are  treated  as  though  they  are  positive,  and  mixed 
ones  generate  an  error.  Type  variables  appearing  in  references  behave  as  though  they  are 
mixed,  so  the  prototype  does  not  implement  references  either. 

Typically  the  refinement  type  of  a  function  is  very  large,  and  we  are  only  interested 
in  a  small  pan  of  it.  For  example,  we  can  verify  that  toCnf  has  the  type  T  &0O<ezF  — *■  cnf 
fairly  quickly,  but  there  are  several  refinements  of  boolexp,  so  it  takes  a  while  to  print 
the  entire  type  of  toCnf.  The  implementation  needs  to  be  more  careful  not  to  print  these 
expensive-to-compute  types. 

For  a  similar  reason,  when  a  refinement  type  error  occurs,  it  is  difficult  to  discover  why. 
A  good  approach  to  this  might  be  to  provide  an  interactive  dialogue  so  the  user  can  ask  the 
type  inference  engine  questions  about  how  the  error  occurred.  This  has  been  explored  for 
ML  [Wan86]. 

Refinement  type  inference  can  in  principle  be  used  to  make  code  more  efficient.  For 
example,  in  the  expression 


case  latte jus  y  of 

cons  (x,  nil)  =>  print  x 

refinement  type  inference  could  guarantee  to  the  compiler  that  the  value  returned  by 
lastcons  will  be  a  cons  cell,  so  the  case  statement  does  not  have  to  verify  this. 
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